4.1.  Abbreviated terms

The following abbreviated terms are used in this document:

AEC

Architecture, Engineering, Construction

ALKIS

German National Standard for Cadastral Information

ATKIS

German National Standard for Topographic and Cartographic Information

B-Rep

Boundary Representation

bSI

buildingSMART International

CAD

Computer Aided Design

COLLADA

Collaborative Design Activity

CSG

Constructive Solid Geometry

DTM

Digital Terrain Model

DXF

Drawing Exchange Format

ESRI

Environmental Systems Research Institute

EuroSDR

European Spatial Data Research Organisation

FM

Facility Management

GDF

Geographic Data Files

GDI-DE

Spatial Data Infrastructure Germany (Geodateninfrastruktur Deutschland)

GDI NRW

Geodata Infrastructure North-Rhine Westphalia

GML

Geography Markup Language

IAI

International Alliance for Interoperability (now buildingSMART International (bSI))

IETF

Internet Engineering Task Force

IFC

Industry Foundation Classes

ISO

International Organization for Standardisation

LOD

Level of Detail

NBIMS

National Building Information Model Standard

OASIS

Organisation for the Advancement of Structured Information Standards

OGC

Open Geospatial Consortium

OSCRE

Open Standards Consortium for Real Estate

SIG 3D

Special Interest Group 3D of the GDI-DE

TC211

ISO Technical Committee 211

TIC

Terrain Intersection Curve

TIN

Triangulated Irregular Network

UML

Unified Modeling Language

URI

Uniform Resource Identifier

VRML

Virtual Reality Modeling Language

WFS

OGC Web Feature Service

W3C

World Wide Web Consortium

W3DS

OGC Web 3D Service

xAL

OASIS extensible Address Language

XML

Extensible Markup Language

X3D

Open Standards XML-enabled 3D file format of the Web 3D Consortium

2D

Two Dimensional

3D

Three Dimensional

4.2.  UML Notation

The CityGML standard is presented in this document in diagrams using the Unified Modeling Language (UML) static structure diagram (see Booch et al. 1997). The UML notations used in this standard are described in the diagram below (Figure 6).

Figure 6 — UML notation (see ISO TS 19103, Geographic information — Conceptual schema language).

According to GML3 all associations between model elements in CityGML are uni-directional. Thus, associations in CityGML are navigable in only one direction. The direction of navigation is depicted by an arrowhead. In general, the context an element takes within the association is indicated by its role. The role is displayed near the target of the association. If the graphical representation is ambiguous though, the position of the role has to be drawn to the element the association points to.

The following stereotypes are used:

<<Geometry>> represents the geometry of an object. The geometry is an identifiable and distinguishable object that is derived from the abstract GML type AbstractGeometryType.

<<Feature>> represents a thematic feature according to the definition in ISO 19109. A feature is an identifiable and distinguishable object that is derived from the abstract GML type AbstractFeatureType.

<<Object>> represents an identifiable and distinguishable object that is derived from the abstract GML type AbstractGMLType.

<<Enumeration>> enumerates the valid attribute values in a fixed list of named literal values. Enumerations are specified inline the CityGML schema.

<<CodeList>> enumerates the valid attribute values. In contrast to Enumeration, the list of values is open and, thus, not given inline the CityGML schema. The allowed values can be provided within an external code list. It is recommended that code lists are implemented as simple dictionaries following the GML 3.1.1 Simple Dictionary Profile (cf. Clause 6.6 and Clause 10.14).

<<Union>> is a list of attributes. The semantics are that only one of the attributes can be present at any time.

<<PrimitiveType>> is used for representations supported by a primitive type in the implementation.

<<DataType>> is used as a descriptor of a set of values that lack identity. Data types include primitive predefined types and user-definable types. A DataType is thus a class with few or no operations whose primary purpose is to hold the abstract state of another class for transmittal, storage, encoding or persistent storage.

<<Leaf>> is used within UML package diagrams to indicate model elements that can have no further subtypes.

<<XSDSchema>> is used within UML package diagrams to denote the root element of an XSD Schema containing all the definitions for a particular namespace. All the package contents or component classes are placed within the one schema.

<<ApplicationSchema>> is used within UML package diagrams to denote an XML Schema definition fundamentally dependent on the concepts of another independent Standard within the XML Schema metalanguage. For example, ApplicationSchema indicates extensions of GML consistent with the GML “rules for application schemas”.

In order to enhance the readability of the CityGML UML diagrams, classes are depicted in different colors if they belong to different UML packages (see Figure 13 for an overview of UML packages). The following coloring scheme is applied:

• Classes painted in yellow belong to the UML package which is subject of discussion in that clause of the specification in which the UML diagram is given. For example, in the context of Clause 10.1 which introduces the CityGML Core module, the yellow color is used to denote classes which are defined in the CityGML Core UML package. Likewise, the yellow classes shown in UML diagrams in Clause 10.3 are associated with the Building module which is subject of discussion in that chapter.

• Classes painted in blue belong to a CityGML UML package different to that associated with the yellow color. In order to explicitly denote the UML package of such classes, their class names carry a namespace prefix which is uniquely associated with a CityGML module throughout this specification (cf. section 4.3 for a list of namespaces and prefixes). For example, in the context of the Building module, classes from the CityGML Core module are painted in blue and their class names are preceded by the prefix core. * Classes painted in green are defined in GML3 and their class names are preceded by the prefix gml.

The following example UML diagram demonstrates the UML notation and coloring scheme used throughout this specification. In this example, the yellow classes are associated with the CityGML Building module, the blue classes are from the CityGML Core module, and the green class depicts a geometry element defined by GML3.

Figure 7 — Example UML diagram demonstrating the UML notation and coloring scheme used throughout the CityGML specification.

4.3.  XML namespaces and namespace prefixes

The CityGML data model is thematically decomposed into a core module and thematic extension modules. All modules including the core are specified by their own XML schema file, each defining a globally unique XML namespace. The extension modules are based on the core module and, thus, contain (by reference) the CityGML core schema.

Within this document the module namespaces are associated with recommended prefixes. These prefixes are consistently used within the normative parts of this specification, for all UML diagrams and example CityGML instance documents. The CityGML core and extension modules along with their XML namespace identifiers and recommended namespace prefixes are listed in Table 1.

Table 1 — List of CityGML modules, their associated XML namespace identifiers, and example namespace prefixes.

Further XML Schema definitions relevant to this standard are shown in Table 2 along with the corresponding XML namespace identifiers and namespace prefixes consistently used within this document.

Table 2 — List of XML Schema definitions, their associated XML namespace identifiers, and example namespace prefixes used within this document.

4.4.  XML-Schema

The normative parts of the standard use the W3C XML schema language to describe the grammar of conformant CityGML data instances. XML schema is a rich language with many capabilities. While a reader who is unfamiliar with an XML schema may be able to follow the description in a general fashion, this standard is not intended to serve as an introduction to XML schema. In order to have a full understanding of this candidate standard, it is necessary for the reader to have a reasonable knowledge of XML schema.

6.1.  Modularisation

The CityGML data model consists of class definitions for the most important types of objects within virtual 3D city models. These classes have been identified to be either required or important in many different application areas. However, implementations are not required to support the overall CityGML data model in order to be conformant to the standard, but may employ a subset of constructs according to their specific information needs. For this purpose, modularisation is applied to the CityGML data model (cf. Clause 7).

The CityGML data model is thematically decomposed into a core module and thematic extension modules. The core module comprises the basic concepts and components of the CityGML data model and, thus, must be implemented by any conformant system. Based on the core module, each extension covers a specific thematic field of virtual 3D city models. CityGML introduces the following thirteen thematic extension modules: Appearance, Bridge, Building, CityFurniture, CityObjectGroup, Generics, LandUse, Relief, Transportation, Tunnel, Vegetation, WaterBody, and TexturedSurface [deprecated].

CityGML compliant implementations may support any combination of extension modules in conjunction with the core module. Such combinations of modules are called CityGML profiles. Therefore, CityGML profiles allow for valid partial implementations of the overall CityGML data model.

6.2.  Multi-scale modelling (5 levels of detail, LOD)

CityGML supports different Levels of Detail (LOD). LODs are required to reflect independent data collection processes with differing application requirements. Further, LODs facilitate efficient visualisation and data analysis (see Figure 8). In a CityGML dataset, the same object may be represented in different LOD simultaneously, enabling the analysis and visualisation of the same object with regard to different degrees of resolution. Furthermore, two CityGML data sets containing the same object in different LOD may be combined and integrated. However, it will be within the responsibility of the user or application to make sure objects in different LODs refer to the same real-world object.

The coarsest level LOD0 is essentially a two and a half dimensional Digital Terrain Model over which an aerial image or a map may be draped. Buildings may be represented in LOD0 by footprint or roof edge polygons. LOD1 is the well-known blocks model comprising prismatic buildings with flat roof structures. In contrast, a building in LOD2 has differentiated roof structures and thematically differentiated boundary surfaces. LOD3 denotes architectural models with detailed wall and roof structures potentially including doors and windows. LOD4 completes a LOD3 model by adding interior structures for buildings. For example, buildings in LOD4 are composed of rooms, interior doors, stairs, and furniture. In all LODs appearance information such as high-resolution textures can be mapped onto the structures (cf. Clause 6.9).

Figure 8 — The five levels of detail (LOD) defined by CityGML (source: IGG Uni Bonn)

LODs are also characterised by differing accuracies and minimal dimensions of objects (cf. Table 3). The accuracy requirements given in this standard are debatable and are to be considered as discussion proposals. Accuracy is described as standard deviation $\sigma$ of the absolute 3D point coordinates. Relative 3D point accuracy will be added in a future version of CityGML and it is typically much higher than the absolute accuracy. In LOD1, the positional and height accuracy of points should be 5m or less, while all objects with a footprint of at least 6m by 6m should be considered. The positional and height accuracy of LOD2 is proposed to be 2m or better. In this LOD, all objects with a footprint of at least 4m × 4m should be considered. Both types of accuracies in LOD3 should be 0.5m, and the minimal footprint is suggested to be 2m × 2m. Finally, the positional and height accuracy of LOD4 should be 0.2m or less. By means of these figures, the classification in five LOD may be used to assess the quality of 3D city model datasets. The LOD categorisation makes datasets comparable and provides support for their integration.

Table 3 — LOD 0-4 of CityGML with their proposed accuracy requirements (discussion proposal, based on: Albert et al. 2003).

Whereas in CityGML each object can have a different representation for every LOD, often different objects from the same LOD will be generalised to be represented by an aggregate object in a lower LOD. CityGML supports the aggregation / decomposition by providing an explicit generalisation association between city objects(further details see UML diagram in Clause 10.1).

6.3.  Coherent semantical-geometrical modelling

One of the most important design principles for CityGML is the coherent modelling of semantics and geometrical/topological properties. At the semantic level, real-world entities are represented by features, such as buildings, walls, windows, or rooms. The description also includes attributes, relations and aggregation hierarchies (part-whole-relations) between features. Thus the part-of-relationship between features can be derived at the semantic level only, without considering geometry. However, at the spatial level, geometry objects are assigned to features representing their spatial location and extent. So the model consists of two hierarchies: the semantic and the geometrical in which the corresponding objects are linked by relationships (cf. Stadler & Kolbe 2007). The advantage of this approach is that it can be navigated in both hierarchies and between both hierarchies arbitrarily, for answering thematic and/or geometrical queries or performing analyses.

If both hierarchies exist for a specific object, they must be coherent (i.e. it must be ensured that they match and fit together). For example, if a wall of a building has two windows and a door on the semantic level, then the geometry representing the wall must contain also the geometry parts of both windows and the door.

6.4.  Closure surfaces

Objects, which are not modelled by a volumetric geometry, must be virtually closed in order to compute their volume (e.g. pedestrian underpasses or airplane hangars). They can be sealed using a ClosureSurface. These are special surfaces, which are taken into account, when needed to compute volumes and are neglected, when they are irrelevant or not appropriate, for example in visualisations.

The concept of ClosureSurface is also employed to model the entrances of subsurfaceobjects. Those objects like tunnels or pedestrian underpasses have to be modelled as closed solids in order to compute their volume, for example in flood simulations. The entrances to subsurface objects also have to be sealed to avoid holes in the digital terrain model (see Figure 9). However, in close-range visualisations the entrance must be treated as open. Thus, closure surfaces are an adequate way to model those entrances.

Figure 9-1 — Passages are subsurface objects

Figure 9-2 — The entrance is sealed by a virtual ClosureSurface, which is both part of the DTM and the subsurface object

Figure 9 — Closure surfaces to seal open structures. (graphic: IGG Uni Bonn).

6.5.  Terrain Intersection Curve (TIC)

A crucial issue in city modelling is the integration of 3D objects and the terrain. Problems arise if 3D objects float over or sink into the terrain. This is particularly the case if terrains and 3D objects in different LOD are combined, or if they come from different providers (Kolbe and Gröger 2003). To overcome this problem, the TerrainIntersectionCurve (TIC) of a 3D object is introduced. These curves denote the exact position, where the terrain touches the 3D object (see Figure 10). TICs can be applied to buildings and building parts (cf. Clause 10.3), bridge, bridge parts and bridge construction elements (cf. Clause 10.5), tunnel and tunnel parts (cf. Clause 10.4), city furniture objects (cf. Clause 10.9), and generic city objects (cf. Clause 10.12). If, for example, a building has a courtyard, the TIC consists of two closed rings: one ring representing the courtyard boundary, and one which describes the building’s outer boundary. This information can be used to integrate the building and a terrain by ‘pulling up’ or ‘pulling down’ the surrounding terrain to fit the TerrainIntersectionCurve. The DTM may be locally warped to fit the TIC. By this means, the TIC also ensures the correct positioning of textures or the matching of object textures with the DTM. Since the intersection with the terrain may differ depending on the LOD, a 3D object may have different TerrainIntersectionCurves for all LOD.

Figure 10-1 — TerrainIntersectionCurve for a building

Figure 10-2 — TerrainIntersectionCurve for a tunnel object. The tunnel’s hollow space is sealed by a triangulated ClosureSurface

Figure 10 — TerrainIntersectionCurve (graphic: IGG Uni Bonn).

6.6.  Code lists for enumerative attributes

CityGML feature types often include attributes whose values can be enumerated in a list of discrete values. An example is the attribute roof type of a building, whose attribute values typically are saddle back roof, hip roof, semi-hip roof, flat roof, pent roof, or tent roof. If such an attribute is typed as string, misspellings or different names for the same notion obstruct interoperability. Moreover, the list of possible attribute values often is not fixed and may substantially vary for different countries (e.g., due to national law and regulations) and for different information communities.

In CityGML, such enumerative attributes are of type gml:CodeType and their allowed attribute values can be provided in a code list which is specified outside the CityGML schema. A code list contains coded attribute values and ensures that the same code is used for the same notion or concept. If a code list is provided for an enumerative attribute, the attribute may only take values from this list. This allows applications to validate the attribute value and thus facilitates semantic and syntactic interoperability. It is recommended that code lists are implemented as simple dictionaries following the GML 3.1.1 Simple Dictionary Profile (cf. Whiteside 2005).

The governance of code lists is decoupled from the governance of the CityGML schema and specification. Thus, code lists may be specified by any organisation or information community according to their information needs. There shall be one authority per code list who is in charge of the code list values and the maintenance of the code list. Further information on the CityGML code list mechanism is provided in Clause 10.14.

Code lists can have references to existing models. For example, room codes defined by the Open Standards Consortium for Real Estate (OSCRE) can be referenced or classifications of buildings and building parts introduced by the National Building Information Model Standard (NBIMS) can be used. Annex C contains non-normative code lists proposed by the SIG 3D for almost all enumerative attributes in CityGML. They can be directly referenced in CityGML instance documents and serve as an example for the definition of code lists.

6.7.  External references

3D objects are often derived from or have relations to objects in other databases or data sets. For example, a 3D building model may have been constructed from a two-dimensional footprint in a cadastre data set, or may be derived from an architectural model (Figure 11). The reference of a 3D object to its corresponding object in an external data set is essential, if an update must be propagated or if additional data is required, for example the name and address of a building’s owner in a cadastral information system or information on antennas and doors in a facility management system. In order to supply such information, each _CityObject may refer to external data sets (for the UML diagram see Figure 27; and for XML schema definition see Annex A.1) using the concept of ExternalReference. Such a reference denotes the external information system and the unique identifier of the object in this system. Both are specified as a Uniform Resource Identifier (URI), which is a generic format for references to any kind of resources on the internet. The generic concept of external references allows for any _CityObject an arbitrary number of links to corresponding objects in external information systems (e.g. ALKIS, ATKIS, OS MasterMap^®, GDF, etc.).

Figure 11 — External references (graphic: IGG Uni Bonn).

6.8.  City object groups

The grouping concept of CityGML allows for the aggregation of arbitrary city objects according to user-defined criteria, and to represent and transfer these aggregations as part of a city model (for the UML diagram see Clause 10.11; XML schema definition see Annex A.6). A group may be assigned one or more names and may be further classified by specific attributes, for example, “escape route from room no. 43 in house no. 1212 in a fire scenario” as a name and ”escape route” as type. Each member of the group can optionally be assigned a role name, which specifies the role this particular member plays in the group. This role name may, for example, describe the sequence number of this object in an escape route, or in the case of a building complex, denote the main building.

A group may contain other groups as members, allowing nested grouping of arbitrary depth. The grouping concept is delivered by the thematic extension module CityObjectGroup of CityGML (cf. Clause 10.11).

6.9.  Appearances

Information about a surface’s appearance, i.e. observable properties of the surface, is considered an integral part of virtual 3D city models in addition to semantics and geometry. Appearance relates to any surface-based theme, e.g. infrared radiation or noise pollution, not just visual properties. Consequently, data provided by appearances can be used as input for both presentation of and analysis in virtual 3D city models.

CityGML supports feature appearances for an arbitrary number of themes per city model. Each LOD of a feature can have an individual appearance. Appearances can represent — among others — textures and georeferenced textures. CityGML’s appearance model is packaged within its own extension module Appearance (cf. Clause 9).

6.10.  Prototypic objects / scene graph concepts

In CityGML, objects of equal shape like trees and other vegetation objects, traffic lights and traffic signs can be represented as prototypes which are instantiated multiple times at different locations (Figure 12). The geometry of prototypes is defined in local coordinate systems. Every instance is represented by a reference to the prototype, a base point in the world coordinate reference system and a transformation matrix that facilitates scaling, rotation, and translation of the prototype. The principle is adopted from the concept of scene graphs used in computer graphics standards like VRML and X3D. As the GML3 geometry model does not provide support for scene graph concepts, it is implemented as an extension to the GML3 geometry model (for further description cf. Clause 8.2).

Figure 12 — Examples of prototypic shapes (source: Rheinmetall Defence Electronics).

6.11.  Generic city objects and attributes

CityGML is being designed as a universal topographic information model that defines object types and attributes which are useful for a broad range of applications. In practical applications the objects within specific 3D city models will most likely contain attributes which are not explicitly modelled in CityGML. Moreover, there might be 3D objects which are not covered by the thematic classes of CityGML. CityGML provides two different concepts to support the exchange of such data: 1) generic objects and attributes, and 2) Application Domain Extensions (cf. Clause 6.12).

The concept of generic objects and attributes allows for the extension of CityGML applications during runtime, i.e. any _CityObject may be augmented by additional attributes, whose names, data types, and values can be provided by a running application without any change of the CityGML XML schema. Similarly, features not represented by the predefined thematic classes of the CityGML data model may be modelled and exchanged using generic objects. The generic extensions of CityGML are provided by the thematic extension module Generics (cf. Clause 10.12).

The current version of CityGML does not include, for example, explicit thematic models for embankments, excavations and city walls. These objects may be stored or exchanged using generic objects and attributes.

6.12.  Application Domain Extensions (ADE)

Application Domain Extensions (ADE) specify additions to the CityGML data model. Such additions comprise the introduction of new properties to existing CityGML classes like e.g. the number of habitants of a building or the definition of new object types. The difference between ADEs and generic objects and attributes is, that an ADE has to be defined in an extra XML schema definition file with its own namespace. This file has to explicitly import the XML Schema definition of the extended CityGML modules.

The advantage of this approach is that the extension is formally specified. Extended CityGML instance documents can be validated against the CityGML and the respective ADE schema. ADEs can be defined (and even standardised) by information communities which are interested in specific application fields. More than one ADE can be actively used in the same dataset (further description cf. Clause 10.13).

ADEs may be defined for one or even several CityGML modules providing a high flexibility in adding additional information to the CityGML data model. Thus, the ADE mechanism is orthogonally aligned with the modularisation approach of CityGML. Consequently, there is no separate extension module for ADEs.

In this specification, two examples for ADEs are included:

• An ADE for Noise Immission Simulation (Annex H) which is employed in the simulation of environmental noise dispersion according to the Environmental Noise Directive of the European Commission (2002/49/EC);

• An ADE for Ubiquitous Network Robots Services (Annex I) which demonstrates the usage of CityGML for the navigation of robots in indoor environments.

Further examples for ADEs are the CAFM ADE (Bleifuß et al., 2009) for facility management, the UtilityNetworkADE (Becker et al., 2011) for the integrated 3D modeling of multi-utility networks and their interdependencies, the HydroADE (Schulte and Coors, 2008) for hydrographical applications and the GeoBIM (IFC) ADE (van Berlo et al., 2011) which combines BIM information from IFC (from bSI) with CityGML and is implemented in the open source modelserver BIMserver.org.

7.1.  CityGML core and extension modules

Each CityGML module is specified by its own XML Schema definition file and is defined within an individual and globally unique XML target namespace. According to dependency relations between modules, each module may, in addition, import namespaces associated to such related CityGML modules. However, a single namespace shall not be directly included in two modules. Thus, all elements belonging to one module are associated to the module’s namespace only. By this means, module elements are guaranteed to be properly separated and distinguishable in CityGML instance documents.

Compared to CityGML versions before 1.0, the aforementioned namespace conventions introduce an extra level of complexity to data files as there is no single CityGML namespace any more. In contrast, components of different CityGML modules and, thus, of different namespaces may be arbitrarily mixed within the same CityGML instance document. Furthermore, an application might have to parse instance documents containing elements of modules which are not employed by the application itself. These parsing problems though can easily be overcome by non-”schema-aware” applications, i.e. applications that do not parse and interpret GML application schemas in a generic way. Elements from different namespaces than those declared by the application’s employed CityGML profile could be skipped. Comparable observations have to be made when using CityGML’s Application Domain Extension mechanism (cf. Clause 10.13).

As for version 2.0 of the CityGML standard, there are no two thematic extension modules related by dependency. Thus, all extension modules are truly independent from each other and may be separately supported by implementations. However, the CityGML core module is a dependency for any extension module. This means that the XML schema file of the core module is imported by each XML schema file defining an extension.

The dependency relations between CityGML’s modules are illustrated in Figure 13 using an UML package diagram. Each module is represented by a package. The package names correspond to the module names. A dashed arrow in the figure indicates that the schema at the tail of the arrow depends upon the schema at the head of the arrow. For CityGML modules, a dependency occurs where one schema <import>s another schema and accordingly the corresponding XML namespace. For example, the extension module Building imports the schema of the CityGML Core module. A short description of each module is given in Table 4.

Figure 13 — UML package diagram illustrating the separate modules of CityGML and their schema dependencies. Each extension module (indicated by the leaf packages) further imports the GML 3.1.1 schema definition in order to represent spatial properties of its thematic classes. For readability reasons, the corresponding dependencies have been omitted.

Table 4 — Overview of CityGML’s core and thematic extensions modules.

7.2.  CityGML profiles

A CityGML profile is a combination of thematic extension modules in conjunction with the core module of CityGML. Each CityGML instance document shall employ the CityGML profile appropriate to the provided data. In general, two approaches to employ a CityGML profile within an instance document can be differentiated:

1. CityGML profile definition embedded inline the CityGML instance document

   A CityGML profile can be bound to an instance document using the schemaLocation attribute defined in the XML Schema instance namespace, http://www.w3.org/2001/XMLSchema-instance (commonly associated with the prefix xsi). The xsi:schemaLocation attribute provides a way to locate the XML Schema definition for namespaces defined in an XML instance document. Its value is a whitespace-delimited list of pairs of Uniform Resource Identifiers (URIs) where each pair consists of a namespace followed by the location of that namespace’s XML Schema definition, which is typically a .xsd file.

   By this means, the namespaces of the respective CityGML modules shall be defined within a CityGML instance document. The xsi:schemaLocation attribute then shall be used to provide the location to the respective XML Schema definition of each module. All example instance documents given in Annex G follow this first approach.

2. CityGML profile definition provided by a separate XML Schema definition file

   The CityGML profile may also be specified by its own XML Schema file. This schema file shall combine the appropriate CityGML modules by importing the corresponding XML Schema definitions. For this purpose, the import element defined in the XML Schema namespace shall be used, http://www.w3.org/2001/XMLSchema (commonly associated with the prefix xs). For the xs:import element, the namespace of the imported CityGML module along with the location of the namespace’s XML Schema definition have to be declared. In order to apply a CityGML profile to an instance document, the profile’s schema has to be bound to the instance document using the xsi:schemaLocation attribute. The XML Schema file of the CityGML profile shall not contain any further content.

   The targetNamespace of the profile’s schema shall differ from the namespaces of the imported CityGML modules. The namespace associated with the profile should be in control of the originator of the instance document and must be given as a previously unused and globally unique URI. The profile’s XML Schema file must be available (or accessible on the internet) to everybody parsing the associated CityGML instance document.

The second approach is illustrated by the following example XML Schema definition for the base profile of CityGML. Since the base profile is the union of all CityGML modules, the corresponding XML Schema definition imports each and every CityGML module. By this means, all components of the CityGML data model are available in and may be exchanged by instance documents referencing this example base profile. The schema definition file of the base profile is shipped with the CityGML schema package, and is accessible at http://schemas.opengis.net/citygml/profiles/base/2.0/CityGML.xsd.

<xs:schema xmlns=”http://www.opengis.net/citygml/profiles/base/2.0”xmlns:xs=”http://www.w3.org/2001/XMLSchema”
    targetNamespace=”http://www.opengis.net/citygml/profiles/base/2.0” elementFormDefault=”qualified”
    attributeFormDefault=”unqualified” version=”2.0.0”>
    <xs:import namespace=”http://www.opengis.net/citygml/appearance/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/appearance/2.0/appearance.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/bridge/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/bridge/2.0/bridge.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/building/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/building/2.0/building.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/cityfurniture/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/cityfurniture/2.0/cityFurniture.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/cityobjectgroup/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/cityobjectgroup/2.0/cityObjectGroup.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/generics/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/generics/2.0/generics.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/landuse/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/landuse/2.0/landUse.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/relief/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/relief/2.0/relief.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/transportation/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/transportation/2.0/transportation.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/tunnel/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/tunnel/2.0/tunnel.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/vegetation/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/vegetation/2.0/vegetation.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/waterbody/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/waterbody/2.0/waterBody.xsd”/>
    <xs:import namespace=”http://www.opengis.net/citygml/texturedsurface/2.0”
                schemaLocation=”http://schemas.opengis.net/citygml/texturedsurface/2.0/texturedSurface.xsd”/>
</xs:schema>

The following excerpt of a CityGML dataset exemplifies how to apply the base profile schema CityGML.xsd to a CityGML instance document. The dataset contains two building objects and a city object group. The base profile defined by CityGML.xsd is referenced using the xsi:schemaLocation attribute of the root element. Thus, all CityGML modules are employed by the instance document and no further references to the XML Schema documents of the CityGML modules are necessary.

<core:CityModel xmlns=”http://www.opengis.net/citygml/profiles/base/2.0”
    xmlns:core=”http://www.opengis.net/citygml/2.0”
    xmlns:bldg=”http://www.opengis.net/citygml/building/2.0”
    xmlns:grp=”http://www.opengis.net/citygml/cityobjectgroup/2.0”
    xmlns:gml=”http://www.opengis.net/gml”
    xmlns:xAL=”urn:oasis:names:tc:ciq:xsdschema:xAL:2.0”
    xmlns:xlink=”http://www.w3.org/1999/xlink”
    xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
    xsi:schemaLocation=”http://www.opengis.net/citygml/profiles/base/2.0
                        http://schemas.opengis.net/citygml/profiles/base/2.0/CityGML.xsd”>
    <core:cityObjectMember>
        <bldg:Building gml:id=”Build0815”>
            <core:externalReference>
                <core:informationSystem>http://www.adv-online.de</core:informationSystem>
                <core:externalObject>
                    <core:uri>urn:adv:oid:DEHE123400007001</core:uri>
                </core:externalObject>
            </core:externalReference>
            <bldg:function
                codeSpace=”http://www.sig3d.org/codelists/standard/building/2.0/_AbstractBuilding_function.xml”>1000</bldg:function>
            <bldg:yearOfConstruction>1985</bldg:yearOfConstruction>
            <bldg:roofType
                codeSpace=”http://www.sig3d.org/codelists/standard//building/2.0/_AbstractBuilding_roofType.xml”>1030</bldg:roofType>
            <bldg:measuredHeight uom=”#m”>8.0</bldg:measuredHeight>
            <bldg:storeysAboveGround>2</bldg:storeysAboveGround>
            <bldg:storeyHeightsAboveGround uom=”#m”>2.5 2.5</bldg:storeyHeightsAboveGround>
            <bldg:lod2Solid> … </bldg:lod2Solid>
        </bldg:Building>
    </core:cityObjectMember>
    <core:cityObjectMember>
        <bldg:Building gml:id=”Build0817”>
        …
        </bldg:Building>
    </core:cityObjectMember>
    <core:cityObjectMember>
        <grp:CityObjectGroup gml:id=”Complex113”>
            <gml:name>Hotel complex ‘Scenic View’</gml:name>
            <grp:function>building group</grp:function>
            <grp:groupMember role=”main building” xlink:href=”#Build0817”/>
            <grp:groupMember xlink:href=”#Build0815”/>
        </grp:CityObjectGroup>
    </core:cityObjectMember>
</core:CityModel>

8.1.  Geometric-topological model

The geometry model of GML3 consists of primitives, which may be combined to form complexes, composite geometries or aggregates. For each dimension, there is a geometrical primitive: a zero-dimensional object is a Point, a one-dimensional a _Curve, a two-dimensional a _Surface, and a three-dimensional a _Solid (Figure 14). Each geometry can have its own coordinate reference system. A solid is bounded by surfaces and a surface by curves. In CityGML, a curve is restricted to be a straight line, thus only the GML3 class LineString is used. Surfaces in CityGML are represented by Polygons, which define a planar geometry, i.e. the boundary and all interior points are required to be located in one single plane.

Figure 14 — UML diagram of CityGML’s geometry model (subset and profile of GML3): Primitives and Composites.

Combined geometries can be aggregates, complexes or composites of primitives (see illustration in Figure 16). For an aggregate, the spatial relationship between components is not restricted. They may be disjoint, overlapping, touching, or disconnected. GML3 provides a special aggregate for each dimension, a MultiPoint, a MultiCurve, a MultiSurface,and a MultiSolid (see Figure 15). In contrast to aggregates, a complex is topologically structured: its parts must be disjoint, must not overlap and are allowed to touch, at most, at their boundaries or share parts of their boundaries. A composite is a special complex provided by GML3. It can only contain elements of the same dimension. Its elements must be disjoint as well, but they must be topologically connected along their boundaries. A composite can be a CompositeSolid, a CompositeSurface, or CompositeCurve. (cf. Figure 14).

Figure 15 — UML diagram of CityGML’s geometry model: Complexes and Aggregates

An OrientableSurface is a surface with an explicit orientation, i.e. two sides, front and back, can be distinguished. This may be used to assign textures to specific sides of a surface, or to distinguish the exterior and the interior side of a surface when bounding a solid. Please note, that curves and surfaces have a default orientation in GML which results from the order of the defining points. Thus, an OrientableSurface only has to be used, if the orientation of a given GML geometry has to be reversed.

TriangulatedSurfaces are special surfaces, which specify triangulated irregular networks often used to represent the terrain. While a TriangulatedSurface is a composition of explicit Triangles, the subclass TIN is used to represent a triangulation in an implicit way by a set of control points, defining the nodes of the triangles. The triangulation may be reconstructed using standard triangulation methods (Delaunay triangulation). In addition, break lines and stop lines define contour characteristics of the terrain.

Figure 16 — Combined geometries.

The GML3 composite model realises a recursive aggregation schema for every primitive type of the corresponding dimension. This aggregation schema allows the definition of nested aggregations (hierarchy of components). For example, a building geometry (CompositeSolid) can be composed of the house geometry (CompositeSolid) and the garage geometry (Solid), while the house’s geometry is further decomposed into the roof geometry (Solid) and the geometry of the house body (Solid).

CityGML provides the explicit modelling of topology, for example the sharing of geometry objects between features or other geometries. One part of space is represented only once by a geometry object and is referenced by all features or more complex geometries which are defined or bounded by this geometry object. Thus redundancy is avoided and explicit topological relations between parts are maintained. Basically, there are three cases. First, two features may be defined spatially by the same geometry. For example, if a path is both a transportation feature and a vegetation feature, the surface geometry defining the path is referenced both by the transportation object and by the vegetation object. Second, geometry may be shared between a feature and another geometry. A geometry defining a wall of a building may be referenced twice: by the solid geometry defining the geometry of the building, and by the wall feature. Third, two geometries may reference the same geometry, which is in the boundary of both. For example, a building and an adjacent garage may be represented by two solids. The surface describing the area where both solids touch may be represented only once and it is referenced by both solids. As it can be seen from Figure 17, this requires partitioning of the respective surfaces. In general, Boundary Representation only considers visible surfaces. However, to make topological adjacency explicit and to allow the possibility of deletion of one part of a composed object without leaving holes in the remaining aggregate touching elements are included. Whereas touching is allowed, permeation of objects is not in order to avoid the multiple representation of the same space. However, the use of topology in CityGML is optional.

In order to implement topology, CityGML uses the XML concept of XLinks provided by GML. Each geometry object that should be shared by different geometric aggregates or different thematic features is assigned an unique identifier, which may be referenced by a GML geometry property using a href attribute. CityGML does not deploy the built-in topology package of GML3, which provides separate topology objects accompanying the geometry. This kind of topology is very complex and elaborate. Nevertheless, it lacks flexibility when data sets, which might include or neglect topology, should be covered by the same data model. The XLink topology is simple and flexible and nearly as powerful as the explicit GML3 topology model. However, a disadvantage of the XLink topology is that navigation between topologically connected objects can only be performed in one direction (from an aggregate to its components), not (immediately) bidirectional as it is the case for GML’s built-in topology. An example for CityGML’s topology representation is given in the dataset listed in Annex G.4.

Figure 17 — Recursive aggregation of objects and geometries in CityGML (graphic: IGG Uni Bonn).

The following excerpt of a CityGML example file defines a gml:Polygon with a gml:id wallSurface4711, which is part of the geometry property lod2Solid of a building. Another building being adjacent to the first building references this shared polygon in its geometry representation.

<bldg:Building>
    <bldg:lod2Solid>
        <gml:surfaceMember>
            <gml:Polygon gml:id="wallSurface4711">
                <gml:exterior>
                    <gml:LinearRing>
                        <gml:pos srsDimension="3">32.0 31.0 2.5</gml:pos>
                        ...
                    </gml:LinearRing>
                </gml:exterior>
            </gml:Polygon>
        </gml:surfaceMember>
        ...
    </bldg:lod2Solid>
</bldg:Building>
...
<bldg:Building>
    <bldg:lod2Solid>
        <gml:surfaceMember>
            <gml:OrientableSurface orientation="-">
                <gml:baseSurface xlink:href="#wallSurface4711"/>
            </gml:OrientableSurface>
        </gml:surfaceMember>
        ...
    </bldg:lod2Solid>
</bldg:Building>

8.2.  Spatial reference system

When dealing with geoinformation and virtual 3D city models in particular, the exact spatial reference is of utmost importance and a key requirement for the integration of different spatial datasets in a single 3D city model. CityGML inherits GML3’s spatial capabilities of handling Coordinate Reference Systems (CRS) which is the usual way of denoting the spatial reference in GML 3.1.1. As CityGML is a true 3D standard, geometry elements are associated with a 3D CRS. There are only few exceptions to this rule where CityGML allows a 2D geometry element (for example, the referencePoint of a GeoreferencedTexture defined in CityGML’s Appearance module must be given with 2D coordinate values, cf. Clause 9.4).

In general, a geometry may point to the CRS definition used by this geometry through the attribute srsName which is inherited from the abstract GML superclass gml:_Geometry. This may be a reference to a well-known CRS definition provided by an authority organization such as the European Petroleum Survey Group (EPSG), but may also be a pointer to a CRS that is locally defined within the same CityGML instance document. The OGC document “Definition identifier URNs in OGC namespace” (cf. Whiteside 2009; OGC Doc. No. 07-092r3) provides best practices for the URN encoding of CRS references. Amongst others, it describes how to reference a single well-known 3D CRS definition (such as a 3D geographic CRS) as well as a compound CRS which combines two or more well-known CRS definitions (e.g., a projected CRS for the planimetry with a vertical CRS for the height reference). Examples for denoting a compound CRS for a CityGML instance document are given in Annex G.

GML3 also supports the definition of engineering CRSs which are used in a contextually local sense. For example, this might be a local 3D Cartesian coordinate system that is essentially based on a flat-earth approximation of the earth’s surface, and thus ignores the effect of earth curvature on feature geometry (cf. chapter 12.1.4.4 of the GML 3.1.1 specification document). Local engineering CRSs are commonly applied in the AEC/FM domain and thus are useful when integrating CAD data or BIM models into a 3D city model. Annex G.9 provides an example demonstrating the definition of an engineering CRS within a CityGML instance document and the use of local coordinate values for the feature geometry. The definition of an engineering CRS requires an anchor point which relates the origin of the local coordinate system to a point on the earth’s surface in order to facilitate the transformation of coordinates from the local engineering CRS.

According to GML 3.1.1, if no srsName attribute is given on a geometry element, then the CRS shall be specified as part of the larger context this geometry element is part of, e.g. a geometric aggregate. For convenience in constructing feature and feature collection instances, the value of the srsName attribute on the gml:Envelope (or gml:Box) which is the value of the gml:boundedBy property of the feature shall be inherited by all directly expressed geometries in all properties of the feature or members of the collection, unless overruled by the presence of a local srsName. Thus it is not necessary for a geometry to carry an srsName attribute if it uses the same CRS as given on the gml:boundedBy property of its parent feature. Inheritance of the CRS continues to any depth of nesting, but if overruled by a local srsName declaration, then the new CRS is inherited by all its children in turn (cf. Clause 8.3 of the GML 3.1.1 specification document).

It is strongly recommended that any CityGML instance document explicitly specifies the CRS for all contained geometry elements. This is especially important if the instance document is to be exchanged externally with third parties or is to be integrated with other spatial datasets. A mixed usage of different CRSs within the same dataset is possible and conformant with GML 3.1.1, whereas a single CRS reference given on the embracing CityModel feature collection (cf. Clause 10.1) simplifies the processing of the dataset by software systems. As for CityGML 2.0, this recommendation is non-normative and thus not accompanied by a conformance class. The main reason for this is to maintain backwards compatibility with CityGML 1.0.

8.3.  Implicit geometries, prototypic objects, scene graph concepts

The concept of implicit geometries is an enhancement of the geometry model of GML3. It is, for example, used in CityGML’s building, bridge, tunnel, and vegetation model as well as for city furniture and generic objects. Implicit geometries may be applied to features from different thematic fields of CityGML in order to geometrically represent the features within a specific level of detail (LOD). Thus, each extension module may define spatial properties providing implicit geometries for its thematic classes. For this reason, the concept of implicit geometries is defined within the CityGML core module (cf. Clause 10.1). However, its description is drawn here since implicit geometries are part of CityGML’s spatial model. The UML diagram is depicted in Figure 18. The corresponding XML schema definition is provided in Annex A.1.

An implicit geometry is a geometric object, where the shape is stored only once as a prototypical geometry, for example a tree or other vegetation objects, a traffic light or a traffic sign. This prototypic geometry object is re-used or referenced many times, wherever the corresponding feature occurs in the 3D city model. Each occurrence is represented by a link to the prototypic shape geometry (in a local cartesian coordinate system), by a transformation matrix that is multiplied with each 3D coordinate of the prototype, and by an anchor point denoting the base point of the object in the world coordinate reference system. This reference point also defines the CRS to which the world coordinates belong after the application of the transformation. In order to determine the absolute coordinates of an implicit geometry, the anchor point coordinates have to be added to the matrix multiplication results. The transformation matrix accounts for the intended rotation, scaling, and local translation of the prototype. It is a 4×4 matrix that is multiplied with the prototype coordinates using homogeneous coordinates, i.e. (x,y,z,1). This way even a projection might be modelled by the transformation matrix.

Figure 18 — UML diagram of ImplicitGeometries. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The reason for using the concept of implicit geometries in CityGML is space efficiency. Since the shape of, for example, trees of the same species can be treated as identical, it would be inefficient to model the detailed geometry of each of the large number of trees explicitly. The concept of implicit geometries is similar to the well known concept of primitive instancing used for the representation of scene graphs in the field of computer graphics (Foley et al. 1995).

The term implicit geometry refers to the principle that a geometry object with a complex shape can be simply represented by a base point and a transformation, implicitly unfolding the object’s shape at a specific location in the world coordinate system.

The shape of an ImplicitGeometry can be represented in an external file with a proprietary format, e.g. a VRML file, a DXF file, or a 3D Studio MAX file. The reference to the implicit geometry can be specified by an URI pointing to a local or remote file, or even to an appropriate web service. Alternatively, the shape can be defined by a GML3 geometry object. This has the advantage that it can be stored or exchanged inline within the CityGML dataset. Typically, the shape of the geometry is defined in a local coordinate system where the origin lies within or near to the object’s extent. If the shape is referenced by an URI, also the MIME type of the denoted object has to be specified (e.g. “model/vrml” for VRML models or “model/x3d+xml” for X3D models).

The implicit representation of 3D object geometry has some advantages compared to the explicit modelling, which represents the objects using absolute world coordinates. It is more space-efficient, and thus more extensive scenes can be stored or handled by a system. The visualisation is accelerated since 3D graphics cards support the scene graph concept. Furthermore, the usage of different shape versions of objects is facilitated, e.g. different seasons, since only the library objects have to be exchanged (see example in Figure 72).

XML namespace

The XML namespace of the CityGML Core module defining the concept of implicit geometries is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/2.0. Within the XML Schema definition of the core module, this URI is also used to identify the default namespace.

<xs:complexType name="ImplicitGeometryType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractGMLType">
            <xs:sequence>
                <xs:element name="mimeType" type="gml:CodeType" minOccurs="0"/>
                <xs:element name="transformationMatrix" type="TransformationMatrix4x4Type" minOccurs="0"/>
                <xs:element name="libraryObject" type="xs:anyURI" minOccurs="0"/>
                <xs:element name="relativeGMLGeometry" type="gml:GeometryPropertyType" minOccurs="0"/>
                <xs:element name="referencePoint" type="gml:PointPropertyType"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- ========================================================================================== -->
<xs:element name="ImplicitGeometry" type="ImplicitGeometryType" substitutionGroup="gml:_GML"/>
<!-- ========================================================================================== -->
<xs:complexType name="ImplicitRepresentationPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="ImplicitGeometry"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

ImplicitGeometryType, ImplicitRepresentationPropertyType

<frn:CityFurniture>
    <!— class “traffic”; as specified in the code list proposed by the SIG 3D (cf. <<a_C-4>>) —>
    <frn:class codeSpace=”http://www.sig3d.org/codelists/standard/cityfurniture/2.0/CityFurniture_class.xml”>1000</frn:class>
    <!— function “traffic light”; as specified in the code list proposed by the SIG 3D (cf. <<a_C-4>>) —>
    <frn:function codeSpace=”http://www.sig3d.org/codelists/standard/cityfurniture/2.0/CityFurniture_function.xml”>1080</frn:function>
    <frn:lod2ImplicitRepresentation>
        <core:ImplicitGeometry>
            <core:mimeType>model/vrml</core:mimeType>
            <core:libraryObject>
                http://www.some-3d-library.com/3D/furnitures/TrafficLight434.wrl
            </core:libraryObject>
            <core:referencePoint>
                <gml:Point srsName=”urn:ogc:def:crs,crs:EPSG:6.12:31467,crs:EPSG:6.12:5783”>
                    <gml:pos srsDimension=”3”>5793898.77 3603845.54 44.8</gml:pos>
                </gml:Point>
            </core:referencePoint>
        </core:ImplicitGeometry>
    </frn:lod2ImplicitRepresentation>
</frn:CityFurniture>

<frn:CityFurniture>
    <!— class “traffic”; as specified in the code list proposed by the SIG 3D (cf. <<a_C-4>>) —>
    <frn:class>1000</frn:class>
    <!— function “traffic light”; as specified in the code list proposed by the SIG 3D (cf. <<a_C-4>>) —>
    <frn:function>1080</frn:function>
    <frn:lod2ImplicitRepresentation>
        <core:ImplicitGeometry>
            <core:mimeType>model/vrml</core:mimeType>
            <core:transformationMatrix>
             0.866025 -0.5 0 0.7
             0.5 0.866025 0 0.8
             0 0 1 0
             0 0 0 1
            </core:transformationMatrix>
            <core:libraryObject>
             http://www.some-3d-library.com/3D/furnitures/TrafficLight434.wrl
            </core:libraryObject>
            <core:referencePoint>
                <gml:Point srsName=”urn:ogc:def:crs,crs:EPSG:6.12:31467,crs:EPSG:6.12:5783”>
                    <gml:pos srsDimension=”3”>5793898.77 3603845.54 44.8</gml:pos>
                </gml:Point>
            </core:referencePoint>
        </core:ImplicitGeometry>
    </frn:lod2ImplicitRepresentation>
</frn:CityFurniture>

9.1.  Relation between appearances, features and geometry

Despite the close relation between surface data and surface, surface data is stored separately in the feature to preserve the original GML geometry model. Instead of surface data being an attribute of the respective target surface geometry object, each surface data object maintains a set of URIs specifying the gml:ids of the target surface geometry objects (of type gml:AbstractSurfaceType or gml:MultiSurface). In case of a composite or aggregate target surface, the surface data object is assigned to all contained surfaces. Other target types such as features, solids, or gml:AbstractSurfacePatchType (which includes gml:Triangle) are invalid, even though the XML schema language cannot formally express constrains on URI target types. For the exact mapping function of surface data values to a surface patch refer to the respective surface data type description.

The limitation of valid target types to gml:AbstractSurfaceType and gml:MultiSurface excluding gml:Abstract­Surface­Patch­Type is based on the GML geometry model and its use in CityGML. In general, GML surfaces are represented using subclasses of gml:AbstractSurfaceType. Such surfaces are required to be continuous. A gml:Multi­Surface does not need to fulfill this requirement and consequently is no gml:AbstractSurfaceType (cf. 8.1). Since captured real-world surfaces often cannot be guaranteed to be continuous, CityGML allows for gml:Multi­Surface to represent a feature’s boundary in various places as an alternative to a continuous surface. To treat such surfaces similarly to a gml:CompositeSurface, surface data objects are allowed to link to gml:Multi­Surface objects. gml:AbstractSurfacePatchType is no valid target type since it is not derived from gml:AbstractGMLType. Thus, a gml:AbstractSurface­PatchType (which includes gml:Triangle and gml:Rectangle) cannot receive a gml:id and cannot be referenced.

Each surface geometry object can have per theme at most one active front-facing material, one active back-facing material, one active front-facing texture, and one active back-facing texture. If multiple surface data objects of the same category and theme are assigned to a surface geometry object, one is chosen to become active. Multiple indirect assignments due to nested surface definitions are resolved by overwriting, e.g. the front-facing material of a gml:Polygon becomes active by overwriting the front-facing material of the parental gml:CompositeSurface. Multiple direct assignments, i.e. a surface geometry object’s gml:id is referenced multiple times within a theme, are not allowed and are resolved implementation-dependently by choosing exactly one of the conflicting surface data objects. Thus, multiple direct assignments within a theme need to be avoided.

Each _CityObject feature can store surface data. Thus, surface data is arranged in the feature hierarchy of a CityGML dataset. Surface data then links to its target surface using URIs. Even though the linking mechanism permits arbitrary links across the feature hierarchy to another feature’s surface, it is recommended to follow the principle of locality: Surface data should be stored such that the linked surfaces only belong to the containing _CityObject feature and its children. “Global” surface data should be stored with the city model. Adhering to the locality principle also ensures that CityObjects retrieved from a WFS will contain the respective appearance information.

The locality principle allows for the following algorithm to find all relevant _SurfaceData objects referring to a given surface geometry object (of type gml:AbstractSurfaceType or gml:MultiSurface) in a given _CityObject:

function findSurfaceData
in: gmlSurface, cityObject
out: frontMaterial, frontTexture, backMaterial, backTexture

1: frontMaterial := empty
2: frontTexture := empty
3: backMaterial := empty
4: backTexture := empty
5: flip := false
6:
7: while (gmlSurface) { // traverse the geometry hierarchy from inner to outer
8:      cObj := cityObject // start from the innermost cityobject
9:
10:     while (cObj) { // traverse the cityobject hierarchy for the current geometry object +
11:         // search all surfaceData objects in all appearance containers
12:         foreach (appearance in cObj) {
13:             foreach (surfaceData in appearance) {
14:                 if (surfaceData refers to gmlSurface) { // if a surfaceData object refers to the geometry object, check its category
15:                     if (flip) { // consider flipping
16:                         // only pick the first surfaceData for a particular category
17:                         if (surfaceData is frontside material AND backMaterial is empty) {
18:                             backMaterial := surfaceData
19:                         }
20:                         if (surfaceData is frontside texture AND backTexture is empty) {
21:                             backTexture := surfaceData
22:                         }
23:                         if (surfaceData is backside material AND frontMaterial is empty) {
24:                             frontMaterial := surfaceData
25:                         }
26:                         if (surfaceData is backside texture AND frontTexture is empty) {
27:                             frontTexture := surfaceData
28:                         }
29:                     } else {
30:                         // only pick the first surfaceData for a particular category
31:                         if (surfaceData is frontside material AND frontMaterial is empty) {
32:                             frontMaterial := surfaceData
33:                         }
34:                         if (surfaceData is frontside texture AND frontTexture is empty) {
35:                             frontTexture := surfaceData
36:                         }
37:                         if (surfaceData is backside material AND backMaterial is empty) {
38:                             backMaterial := surfaceData
39:                         }
40:                         if (surfaceData is backside texture AND backTexture is empty) {
41:                             backTexture := surfaceData
42:                         }
43:                     }
44:
45:                     // shortcut: could stop here if all 4 categories have been found
46:                 }
47:             }
48:         }
49:         cObj := cObj.parent // this also includes the global CityModel
50:     }
51:     gmlSurface := gmlSurface.parent // this also includes a root gml:MultiSurface
52:     if (gmlSurface isA gml:OrientableSurface AND gmlSurface.orientation is negative) {
53:         negate flip
54:     }
55: }

Figure 20 — Algorithm to find all relevant _SurfaceData objects referring to a given surface geometry object (of type gml:AbstractSurfaceType or gml:MultiSurface) in a given _CityObject.

The evaluation of the isFront property of a _SurfaceData object needs to take gml:OrientableSurfaces into account, as those can flip the orientation of a surface. Assume a gml:OrientableSurface os, which flips its base surface bs. A front side texture $t$ targeting bs will appear on the actual front side of bs. If $t$ targets os, it will appear on the back side of bs. If $t$ targets both os and bs, it appears on both sides of bs since it becomes the front and back side texture.

XLinks influence the hierarchy traversal in the pseudocode. In general, the separation of surface data and geometry objects requires the reevaluation of the surface data assignment for each occurrence of a geometry object in the context of the respective _CityObject. Stepping up the (geometry or _CityObject) hierarchy in the algorithm takes XLinks into account, i.e., for the purpose of this algorithm, referenced objects are conceptually copied to the location of the referring XLink. In particular, this applies to ImplicitGeometry objects. If an ImplicitGeometry object contains GML geometry (in the relativeGMLGeometry property), the surface data assignment needs to be reevaluated in the context of each referring _CityObject. Thus, the appearance (but not the relative geometry) of a given ImplicitGeometry can differ between its occurrences. A consistent appearance results if all required surface data objects are placed in Appearance objects and the latter are stored either

1. in the _CityObject containing the original ImplicitGeometry with XLinks referencing the same Appearance objects in all _CityObjects that refer to the ImplicitGeometry or

2. in the global CityModel.

9.2.  Appearance and SurfaceData

The feature class Appearance defines a container for surface data objects. It provides the theme that all contained surface data objects are related to. All appearance objects with the same theme in a CityGML file are considered a group. Surface data objects are stored in the surfaceDataMember property. They can be used in multiple themes simultaneously as remote properties.

The feature class _SurfaceData is the base class for materials and textures. Its only element is the boolean flag isFront, which determines the side a surface data object applies to. Please note, that all classes of the appearance model support CityGML’s ADE mechanism (cf. Clause 6.12 and Clause 10.13). The hooks for application specific extensions are realized by the elements “_GenericApplicationPropertyOf…​”‌.

<xs:complexType name=”AppearanceType”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractFeatureType”>
            <xs:sequence>
                <xs:element name=”theme” type=”xs:string” minOccurs=”0”/>
                <xs:element name=”surfaceDataMember” type=”SurfaceDataPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element ref=”_GenericApplicationPropertyOfAppearance” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Appearance” type=”AppearanceType” substitutionGroup=”gml:_Feature”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfAppearance” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”AppearancePropertyType”>
    <xs:sequence minOccurs=”0”>
        <xs:element ref=”Appearance”/>
    </xs:sequence>
    <xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

AppearanceType, Appearance, AppearancePropertyType

<xs:element name=”appearanceMember” type=”gml:FeaturePropertyType” substitutionGroup=”gml:featureMember”/>
<!— ========================================================================================= —>
<xs:element name=”appearance” type=”AppearancePropertyType” substitutionGroup=”core:_GenericApplicationPropertyOfCityObject”/>

appearanceMember, appearance

The definition of appearanceMember allows for an arbitrary or even mixed sequence of _CityObject features and Appearance features within a CityModel feature collection (cf. Clause 10.1).

In order to store appearance information within a single _CityObject feature, the corresponding abstract class _CityObject of the core module is augmented by the property element appearance. The additional property appearance is injected into _CityObject using CityGML’s Application Domain Extension mechanism (cf. Clause 10.13). By this means, each thematic subclass of _CityObject inherits this property. Thus, the Appearance module has a deliberate impact on each extension module defining thematic subclasses of _CityObject.

<xs:complexType name=”AbstractSurfaceDataType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractFeatureType”>
            <xs:sequence>
                <xs:element name=”isFront” type=”xs:boolean” default=”true” minOccurs=”0”/>
                <xs:element ref=”_GenericApplicationPropertyOfSurfaceData” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_SurfaceData” type=”AbstractSurfaceDataType” abstract=”true” substitutionGroup=”gml:_Feature”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfSurfaceData” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”SurfaceDataPropertyType”>
<xs:sequence minOccurs=”0”>
<xs:element ref=”_SurfaceData” minOccurs=”0”/>
</xs:sequence>
<xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

AbstractSurfaceDataType, _SurfaceData, SurfaceDataPropertyType

9.3.  Material

Materials define light reflection properties being constant for a whole surface geometry object. The definition of the class X3DMaterial is adopted from the X3D and COLLADA specification (cf. X3D, COLLADA specification). diffuseColor defines the color of diffusely reflected light. specularColor defines the color of a directed reflection. emissiveColor is the color of light generated by the surface. All colors use RGB values with red, green, and blue between 0 and 1. Transparency is defined separately using the transparency element where 0 stands for fully opaque and 1 for fully transparent. ambientIntensity defines the minimum percentage of diffuseColor that is visible regardless of light sources. shininess controls the sharpness of the specular highlight. 0 produces a soft glow while 1 results in a sharp highlight. isSmooth gives a hint for normal interpolation. If this boolean flag is set to true, vertex normals should be used for shading (Gouraud shading). Otherwise, normals should be constant for a surface patch (flat shading).

Target surfaces are specified using target elements. Each element contains the URI of one target surface geometry object (of type gml:AbstractSurfaceType or gml:MultiSurface).

<xs:complexType name="X3DMaterialType">
    <xs:complexContent>
        <xs:extension base="AbstractSurfaceDataType">
            <xs:sequence>
                <xs:element name="ambientIntensity" type="core:doubleBetween0and1" default="0.2" minOccurs="0"/>
                <xs:element name="diffuseColor" type="Color" default="0.8 0.8 0.8" minOccurs="0"/>
                <xs:element name="emissiveColor" type="Color" default="0.0 0.0 0.0" minOccurs="0"/>
                <xs:element name="specularColor" type="Color" default="1.0 1.0 1.0" minOccurs="0"/>
                <xs:element name="shininess" type="core:doubleBetween0and1" default="0.2" minOccurs="0"/>
                <xs:element name="transparency" type="core:doubleBetween0and1" default="0.0" minOccurs="0"/>
                <xs:element name="isSmooth" type="xs:boolean" default="false" minOccurs="0"/>
                <xs:element name="target" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
                <xs:element ref="_GenericApplicationPropertyOfX3DMaterial" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="X3DMaterial" type="X3DMaterialType" substitutionGroup="_SurfaceData"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfX3DMaterial" type="xs:anyType" abstract="true"/>

X3DMaterialType, X3DMaterial

9.4.  Texture and texture mapping

The abstract base class for textures is remote _Texture. Textures in CityGML are always raster-based 2D textures. The raster image is specified by imageURI using a URI and can be an arbitrary image data resource, even a preformatted request for a web service. The image data format can be defined using standard MIME types in the mimeType element.

Textures can be qualified by the attribute textureType. The textureType differentiates between textures, which are specific for a certain object (specific) and prototypic textures being typical for that object surface (typical). Textures may also be classified as unknown.

The specification of texture wrapping is adopted from the COLLADA standard. Texture wrapping is required when accessing a texture outside the underlying image raster. wrapMode can have one of five values (Figure 21 illustrates the effect of these wrap modes):

1. none — the resulting color is fully transparent

2. wrap — the texture is repeated

3. mirror — the texture is repeated and mirrored

4. clamp — the texture is clamped to its edges

5. border — the resulting color is specified by the borderColor element (RGBA)

In wrap mode mirror, the texture image is repeated both in horizontal and in vertical direction to fill the texture space similar to wrap mode wrap. Unlike wrap, each repetition results from flipping the previous texture part along the repetition direction. This behaviour removes the edge correspondence constraint for wrapped textures and always results in a seamless texture.

Figure 21 — A texture (a) applied to a facade using different wrap modes: (b) none, © wrap, (d) mirror, (e) clamp and (f) border. The border color is red. The numbers denote texture coordinates (image: Hasso-Plattner-Institute).

<xs:complexType name=”AbstractTextureType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”AbstractSurfaceDataType”>
            <xs:sequence>
                <xs:element name=”imageURI” type=”xs:anyURI”/>
                <xs:element name=”mimeType” type=”gml:CodeType” minOccurs=”0”/>
                <xs:element name=”textureType” type=”TextureTypeType” minOccurs=”0”/>
                <xs:element name=”wrapMode” type=”WrapModeType” minOccurs=”0”/>
                <xs:element name=”borderColor” type=”ColorPlusOpacity” minOccurs=”0”/>
                <xs:element ref=”_GenericApplicationPropertyOfTexture” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_Texture” type=”AbstractTextureType” abstract=”true” substitutionGroup=”_SurfaceData”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfTexture” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:simpleType name=”WrapModeType”>
    <xs:restriction base=”xs:string”>
        <xs:enumeration value=”none”/>
        <xs:enumeration value=”wrap”/>
        <xs:enumeration value=”mirror”/>
        <xs:enumeration value=”clamp”/>
        <xs:enumeration value=”border”/>
    </xs:restriction>
</xs:simpleType>
<!— ========================================================================================= —>
<xs:simpleType name=”TextureTypeType”>
    <xs:restriction base=”xs:string”>
        <xs:enumeration value=”specific”/>
        <xs:enumeration value=”typical”/>
        <xs:enumeration value=”unknown”/>
    </xs:restriction>
</xs:simpleType>

AbstractTextureType, _Texture, WrapModeType, TextureTypeType

remote _Texture is further specialised according to the texture parameterisation, i.e. the mapping function from a location on the surface to a location in the texture image. CityGML uses the notion of texture space, where the texture image always occupies the region [0,1]² regardless of the actual image size or aspect ratio. The lower left image corner is located at the origin (some graphics APIs may use other conventions and require texture coordinate conversion). The mapping function must be known for each surface geometry object to receive texture.

Figure 22 — A georeferenced texture applied to ground and roof surfaces (source: Senate of Berlin, Hasso-Plattner-Institute).

The class GeoreferencedTexture describes a texture that uses a planimetric projection. Consequently, it does not make sense to texture vertical surfaces using a GeoreferencedTexture. Such a texture has a unique mapping function which is usually provided with the image file (e.g. georeferenced TIFF) or as a separate ESRI world file¹. The search order for an external georeference is determined by the boolean flag preferWorldFile. If this flag is set to true (its default value), a world file is looked for first and only if it is not found the georeference from the image data is used. If preferWorldFile is false, the world file is used only if no georeference from the image data is available.

Alternatively, CityGML allows for inline specification of a georeference similar to a world file. This internal georeference specification always takes precedence over any external georeference. referencePoint defines the location of the center of the upper left image pixel in world space and corresponds to values 5 and 6 in an ESRI world file. Since GeoreferencedTexture uses a planimetric projection, referencePoint is two-dimensional. orientation defines the rotation and scaling of the image in form of a 2×2 matrix (a list of 4 doubles in row-major order corresponding to values 1, 3, 2, and 4 in an ESRI world file). The CRS of this transformation is identical to the referencePoint‘s CRS. A planimetric point ${\left(x,y\right)}^T$ in that CRS is transformed to a point ${\left(s,t\right)}^T$ in texture space using the formula:

with $M$ denoting orientation, $P_R$ denoting referencePoint, $w$ the image’s width in pixels, and $h$ the image’s height in pixels. This transformation compensates for the difference between the image coordinate system used in ESRI world files (origin in upper left corner, positive x-axis rightwards, and positive y-axis downwards) and texture space in CityGML (origin in lower left corner, positive x-axis rightwards, and positive y-axis upwards).

If neither an internal nor an external georeference is given the GeoreferencedTexture is invalid. Each target surface geometry object is specified by an URI in a target element. All target surface geometry objects share the mapping function defined by the georeference. No other mapping function is allowed. Please note, that the gml:boundedBy property inherited from gml:AbstractFeatureType could be set to the bounding box of valid image data to allow for spatial queries. Figure 22 shows a georeferenced texture applied to the ground and all roof surfaces.

<xs:complexType name=”GeoreferencedTextureType”>
  <xs:complexContent>
    <xs:extension base=”AbstractTextureType”>
      <xs:sequence>
        <xs:element name=”preferWorldFile” type=”xs:boolean” default=”true” minOccurs=”0”/>
        <xs:element name=”referencePoint” type=”gml:PointPropertyType” minOccurs=”0”/>
        <xs:element name=”orientation” type=”core:TransformationMatrix2×2Type” minOccurs=”0”/>
        <xs:element name=”target” type=”xs:anyURI” minOccurs=”0” maxOccurs=”unbounded”/>
        <xs:element ref=”_GenericApplicationPropertyOfGeoreferencedTexture” minOccurs=”0” maxOccurs=”unbounded”/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”GeoreferencedTexture” type=”GeoreferencedTextureType” substitutionGroup=”_Texture”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfGeoreferencedTexture” type=”xs:anyType” abstract=”true”/>

GeoreferencedTextureType, GeoreferencedTexture

The class ParameterizedTexture describes a texture with target-dependent mapping function. The mapping is defined by subclasses of class remote _TextureParameterization as a property of the link to the target surface geometry object. Each target surface geometry object is specified as URI in the uri attribute of a separate target element. Since target implements gml:AssociationAttributeGroup, it allows referencing to a remote _TextureParameterization object (using the xlink:href attribute), e.g. for sharing a mapping function between targets or textures in different themes. The mapping function can either use the concept of texture coordinates (through class TexCoordList) or a transformation matrix from world space to texture space (through class TexCoordGen).

Figure 23 — Positioning of textures using texture coordinates (image: IGG Uni Bonn).

Texture coordinates are applicable only to polygonal surfaces, whose boundaries are described by gml:LinearRing (e.g., gml:Triangle, gml:Polygon, or a gml:MultiSurface consisting of gml:Polygons). They define an explicit mapping of a surface’s vertices to points in texture space, i.e. each vertex including interior ring vertices must receive a corresponding coordinate pair in texture space (for the notion of coordinates, refer to ISO 19111). These coordinates are not restricted to the [0,1] interval. Texture coordinates for interior surface points are planarly interpolated from the vertices’ texture coordinates. Figure 22 shows an example.

Texture coordinates for a target surface geometry object are specified using class TexCoordList as a texture parameterization object in the texture’s target property. Each exterior and interior gml:LinearRing composing the boundary of the target surface geometry object (which also might be a gml:CompositeSurface, gml:MultiSurface, or gml:TriangulatedSurface) requires its own set of texture coordinates. A set of texture coordinates is specified using the textureCoordinates element of class TexCoordList. Thus, a TexCoordList contains as many textureCoordinate elements as the target surface geometry object contains gml:LinearRings. textureCoordinate‘s mandatory attribute ring provides the gml:id of the respective ring. The content is an ordered list of double values where each two values define a ${\left(s,t\right)}^T$ texture coordinate pair with $s$ denoting the horizontal and $t$ the vertical texture axis. The list contains one pair per ring point with the pairs’ order corresponding to the ring points’ order in the CityGML document (regardless of a possibly flipped surface orientation). If any ring point of a target surface geometry object has no texture coordinates assigned, the mapping is incomplete and the respective surface cannot be textured. In case of aggregated target geometry objects, mapping completeness is determined only for leaf geometry objects.

Figure 24-1

Figure 24-2

Figure 24 — Projecting a photograph (Figure 24-1) onto multiple facades (Figure 24-2) using the worldToTexture transformation. The photograph does not cover the left facade completely. Thus, the texture appears to be clipped. Texture wrapping is set to “none” (source: Senate of Berlin, Hasso-Plattner-Institute).

Alternatively, the mapping function can comprise a 3×4 transformation matrix specified by class TexCoordGen. The transformation matrix, specified by the worldToTexture element, defines a linear transformation from a spatial location in homogeneous coordinates to texture space. The use of homogeneous coordinates facilitates perspective projections as transformation, e.g. for projecting a photograph into a city model (cf. Figure 24). Texture coordinates ${\left(s,t\right)}^T$ are calculated from a space location ${\left(x,y,z\right)}^T$ as ${\left(s,t\right)}^T={\left(s\prime /q,t\prime /q\prime \right)}^T$ with ${\left(s\prime ,t\prime ,q\prime \right)}^T=M\cdot {\left(x,y,z,1\right)}^T$. $M$ denotes the $3\times 4$ transformation matrix. Compared to a general 4×4 transformation, the resulting $z$ component is ignored. Thus, the respective matrix row is omitted. Additionally, the worldToTexture element uses the gml:SRSReferenceGroup attributes to define its CRS. A location in world space has to be first transformed into this CRS before the transformation matrix can be applied.

The following construction results in a worldToTexture transformation that mimics the process of taking a photograph by projecting a location in world space (in the city model) to a location in texture space:

In this formula, $f$ denotes the focal length; $w$ and $h$ represent the image sensor’s physical dimensions; $\overrightarrow{r}$, $\overrightarrow{u}$, and $\overrightarrow{d}$ define the camera’s frame of reference as right, up and directional unit vectors expressed in world coordinates; and $P$ stands for the camera’s location in world space. Figure 25 sketches this setting.

Figure 25 — Projective texture mapping. All points on a ray $R$ starting from the projection center $P$ are mapped to the same point $T$ in texture space (image: Hasso-Plattner-Institute, IGG TU Berlin).

Alternatively, if the $3\times 4$ camera matrix $M_P$ is known (e.g. through a calibration and registration process), it can easily be adopted for use in worldToTexture. $M_P$ is derived from intrinsic and extrinsic camera parameters (interior and exterior orientation) and transforms a location in world space to a pixel location in the image. Assuming the upper left image corner has pixel coordinates (0,0), the complete transformation to texture space coordinates can be written as (${\text{width}}_{\text{image}}$ and ${\text{height}}_{\text{image}}$ denote the image size in pixels):

Please note, that worldToTexture cannot compensate for radial or other non-linear distortions introduced by a real camera lens.

Another use of worldToTexture is texturing a facade with complex geometry without specifying texture coordinates for each gml:LinearRing. Instead, only the facade’s aggregated surface becomes the texture target using a TexCoordGen as parameterization. Then, worldToTexture effectively encodes an orthographic projection of world space into texture space. For the special case of a vertical facade this transformation is given by:

This equation assumes $\overrightarrow{n}$ denoting the facade’s overall normal vector (normalized, pointing outward, and being parallel to the ground), $F$ denoting the facade’s lower left point, and ${\text{width}}_f$ and ${\text{height}}_f$ specifying the facade’s dimensions in world units. For the general case of an arbitrary normal vector the facade orientation matrix assumes a form similar to the camera orientation matrix:

with

<xs:complexType name=”ParameterizedTextureType”>
    <xs:complexContent>
        <xs:extension base=”AbstractTextureType”>
            <xs:sequence>
                <xs:element name=”target” type=”TextureAssociationType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element ref=”_GenericApplicationPropertyOfParameterizedTexture” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”ParameterizedTexture” type=”ParameterizedTextureType” substitutionGroup=”_Texture”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfParameterizedTexture” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”TextureAssociationType”>
    <xs:sequence minOccurs=”0”>
        <xs:element ref=”_TextureParameterization”/>
    </xs:sequence>
    <xs:attribute name=”uri” type=”xs:anyURI” use=”required”/>
    <xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

ParameterizedTextureType, ParameterizedTexture, TextureAssociationType

<xs:complexType name=”AbstractTextureParameterizationType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractGMLType”>
            <xs:sequence>
                <xs:element ref=”_GenericApplicationPropertyOfTextureParameterization” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_TextureParameterization” type=”AbstractTextureParameterizationType” abstract=”true”
            substitutionGroup=”gml:_GML”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfTextureParameterization” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”TexCoordListType”>
    <xs:complexContent>
        <xs:extension base=”AbstractTextureParameterizationType”>
            <xs:sequence>
                <xs:element name=”textureCoordinates” maxOccurs=”unbounded”>
                    <xs:complexType>
                        <xs:simpleContent>
                            <xs:extension base=”gml:doubleList”>
                                <xs:attribute name=”ring” type=”xs:anyURI” use=”required”/>
                            </xs:extension>
                        </xs:simpleContent>
                    </xs:complexType>
                </xs:element>
                <xs:element ref=”_GenericApplicationPropertyOfTexCoordList” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”TexCoordList” type=”TexCoordListType” substitutionGroup=”_TextureParameterization”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfTexCoordList” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”TexCoordGenType”>
    <xs:complexContent>
        <xs:extension base=”AbstractTextureParameterizationType”>
            <xs:sequence>
                <xs:element name=”worldToTexture”>
                    <xs:complexType>
                        <xs:simpleContent>
                            <xs:extension base=”core:TransformationMatrix3×4Type”>
                                <xs:attributeGroup ref=”gml:SRSReferenceGroup”/>
                            </xs:extension>
                        </xs:simpleContent>
                    </xs:complexType>
                </xs:element>
                <xs:element ref=”_GenericApplicationPropertyOfTexCoordGen” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”TexCoordGen” type=”TexCoordGenType” substitutionGroup=”_TextureParameterization”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfTexCoordGen” type=”xs:anyType” abstract=”true”/>

AbstractTextureParameterizationType, TexCoordListType, TexCoordGenType

9.5.  Related concepts

The notion of appearance clearly relates to the generic coverage approach (cf. ISO 19123 and OGC Abstract specification, Topic 6). Surface data can be described as discrete or continuous coverage over a surface as two-dimensional domain with a specific mapping function. Such an implementation requires the extension of GML coverages (as of version 3.1) by suitable mapping functions and specialisation for valid domain and range sets. For reasons of simplicity and comprehensibility both in implementation and usage, CityGML does not follow this approach, but relies on textures and materials as well-known surface property descriptions from the field of computer graphics (cf. X3D, COLLADA specification, Foley et al.). Textures and materials store data as color using an appropriate mapping. If such a mapping is impractical, data storage can be customised using ADEs. A review of coverages for appearance modelling is considered for CityGML beyond version 2.0.0.

Appearance is also related to portrayal. Portrayal describes the composition and symbolisation of a digital model’s image, i.e. presentation, while appearance encodes observations of the real object’s surface, i.e. data. Even though being based on graphical terms such as textures and materials, surface data is not limited to being input for portrayal, but similarly serves as input or output for analyses on a feature’s surface. Consequently, CityGML does not define mixing or composition of themes for portrayal purposes. Portrayal is left to viewer applications or styling specification languages such as OGC Styled Layer Descriptors (SLD) or OGC Symbology Encoding (SE).

9.6.  Code lists

The mimeType attribute of the feature remote _Texture is specified as gml:CodeType. The values of this property can be enumerated in a code list. A proposal for this code list can be found in Annex C.6.

9.7.  Conformance requirements

Base requirements

1. A surface geometry object may be the target of at most two textures and two materials (one for front and back respectively) per theme.

2. The referencePoint property (type: gml:PointPropertyType) of the element GeoreferencedTexture may only contain or reference a point geometry object with 2D coordinate values.

3. Texture coordinates given by the textureCoordinates property of the element TexCoordList define an explicit mapping of a surface’s boundary points to points in texture space. Each boundary point of the surface must receive a corresponding coordinate pair in texture space. The coordinate pair in texture space shall be given as two doubles per boundary point. The order of the coordinate pairs must follow the order of the boundary points in the CityGML document (regardless of a possibly flipped surface orientation). Each gml:LinearRing composing the boundary of the target surface geometry object requires its own set of texture coordinates.

4. A GeoreferencedTexture element must provide either internal or external georeference, otherwise it is invalid. Internal georeference shall be declared by the referencePoint property (type: gml:PointPropertyType) and the orientation property (type: core:TransformationMatrix2×2Type) of the element GeoreferencedTexture. External georeference may be provided by the texture image file itself (e.g. GeoTIFF) or by an accompanying world file.

Referential integrity

1. The appearanceMember element (type: AppearancePropertyType) may contain an Appearance element inline or an XLink reference to a remote Appearance element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the appearanceMember element may only point to a remote Appearance element (where remote Appearance elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

2. The appearance property (type: AppearancePropertyType) of the element core:_CityObject may contain an Appearance element inline or an XLink reference to a remote Appearance element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the appearance property may only point to a remote Appearance element (where remote Appearance elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

3. The surfaceDataMember property (type: SurfaceDataPropertyType) of the element Appearance may contain a remote _SurfaceData element inline or an XLink reference to a remote _SurfaceData element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the surfaceDataMember property may only point to a remote _SurfaceData element (where remote _SurfaceData elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

4. The target property (type: TextureAssociationType) of the element ParameterizedTexture may contain a _TextureParameterization element inline or an XLink reference to a remote _TextureParameterization element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the target property may only point to a remote _TextureParameterization element (where remote _TextureParameterization elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

5. The target property (type xs:anyURI) of the element GeoreferencedTexture shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

6. The uri attribute of the complex type TextureAssociationType shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

7. The ring attribute of the textureCoordinates property of the element TexCoordList shall specify the gml:id of the target surface geometry object which may only be of type gml:LinearRing.

8. The target property (type xs:anyURI) of the element X3DMaterial shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

9.8.  Material model of previous CityGML versions [deprecated]

Since GML3 has no built-in concept for the representation of surface materials, previous versions of CityGML extend the GML3 geometry model by the class TexturedSurface, which allows for assigning appearance properties (colors, shininess, transparency) and textures to 3D surfaces. The definition of the appearance properties is adopted from the X3D specification. This approach for appearance modelling has been deprecated due to inherent limitations. However, in order to provide a certain degree of backwards compatibility for already existing CityGML implementations, the approach has been incorporated into CityGML version 1.0 and version 2.0 as a separate extension module called TexturedSurface. By this means, implementations may employ the old material model by supporting this module. Please note, that appearance information modelled according to the TexturedSurface module can be converted without information loss to the concepts provided by CityGML’s Appearance module that has been introduced in the previous clauses of this chapter. Thus, the use of the TexturedSurface module is strongly discouraged and implementations should only stick to the Appearance module instead. Moreover, the TexturedSurface module is expected to be removed in future versions of CityGML.

For the TexturedSurface module, each surface or composite surface can be specialized to a TexturedSurface, which can be assigned Materials (colors, shininess, transparency) or SimpleTextures. Figure 26 depicts the UML diagram, for XML schema definition see Annex A.14.

Figure 26 — UML diagram of CityGML’s material model. Please note, that this approach for appearance modelling has been marked as deprecated and is expected to be removed in future CityGML versions. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML TexturedSurface module.

The concept of positioning textures on surfaces complies with the 3D computer graphics standard X3D (web 3D 2004), a successor of VRML97. CityGML adds the class TexturedSurface to the geometry model of GML3 because there has been no appropriate texturing concept in ISO 19107 and in GML3.

A texture is specified as a raster image referenced by an URI (Uniform Resource Identifier) and can be an arbitrary resource, even on the internet. Textures are positioned by employing the concept of texture coordinates, i.e. each texture coordinate matches with exactly one 3D coordinate of the TexturedSurface (Figure 23). The use of texture coordinates allows an exact positioning and trimming of the texture on the surface geometry.

The color of a surface is defined by RGB values. These have to be in the range of 0 to 1. The frontOpacity and the backOpacity define the level of transparency of each surface. Their values have also to be in the range of 0 to 1, where 1 means completely covering and 0 denotes a completely transparent surface. The colors can be differentiated in diffuseColor (color when illuminated by a source of light), emissiveColor (color when self-illuminating) and specularColor/shininess (color for shiny surfaces).

Textures can be qualified by the attribute textureType. The textureType differentiates between textures which are specific for a certain object (specific) and prototypic textures being typical for that object surface (typical). Textures may also be classified as unknown.

_Appearanceis derived from gml:AbstractGMLType to be referenced in an appearance property. The attribute gml:id is inherited, whose value may be referenced by a XLink. _Appearance is the parent class of Material and SimpleTexture.

XML namespace

The XML namespace of the CityGML TexturedSurface module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/texturedsurface/2.0. Within the XML Schema definition of the TexturedSurface module, this URI is also used to identify the default namespace.

<xs:complexType name=”TexturedSurfaceType”>
    <xs:complexContent>
        <xs:extension base=”gml:OrientableSurfaceType”>
            <xs:sequence>
                <xs:element ref=”appearance” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”TexturedSurface” type=”TexturedSurfaceType” substitutionGroup=”gml:OrientableSurface”/>
<!— ========================================================================================= —>
<xs:element name=”appearance” type=”AppearancePropertyType”/>
<!— ========================================================================================= —>
<xs:complexType name=”AppearancePropertyType”>
    <xs:sequence minOccurs=”0”>
        <xs:element ref=”_Appearance”/>
    </xs:sequence>
    <xs:attribute name=”orientation” type=”gml:SignType” default=”+”/>
    <xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

<xs:complexType name=”AbstractAppearanceType” abstract=”true”>>
    <xs:complexContent>>
        <xs:extension base=”gml:AbstractGMLType”/>>
    </xs:complexContent>>
</xs:complexType>>
<!— ========================================================================================= —>>
<xs:element name=”_Appearance” type=”AbstractAppearanceType” abstract=”true” substitutionGroup=”gml:_GML”/>>

<xs:complexType name=”MaterialType”>>
    <xs:complexContent>>
        <xs:extension base=”AbstractAppearanceType”>>
            <xs:sequence>>
                <xs:element name=”shininess” type=”core:doubleBetween0and1” minOccurs=”0”/>>
                <xs:element name=”transparency” type=”core:doubleBetween0and1” minOccurs=”0”/>>
                <xs:element name=”ambientIntensity” type=”core:doubleBetween0and1” minOccurs=”0”/>>
                <xs:element name=”specularColor” type=”Color” minOccurs=”0”/>>
                <xs:element name=”diffuseColor” type=”Color” minOccurs=”0”/>>
                <xs:element name=”emissiveColor” type=”Color” minOccurs=”0”/>>
            </xs:sequence>>
        </xs:extension>>
    </xs:complexContent>>
</xs:complexType>>
<!— ========================================================================================= —>>
<xs:element name=”Material” type=”MaterialType” substitutionGroup=”_Appearance”/>>

<xs:complexType name=”SimpleTextureType”>>
    <xs:complexContent>>
        <xs:extension base=”AbstractAppearanceType”>>
            <xs:sequence>>
                <xs:element name=”textureMap” type=”xs:anyURI”/>>
                <xs:element name=”textureCoordinates” type=”gml:doubleList”/>>
                <xs:element name=”textureType” type=”TextureTypeType” minOccurs=”0”/>>
                <xs:element name=”repeat” type=”xs:boolean” minOccurs=”0”/>>
            </xs:sequence>>
        </xs:extension>>
    </xs:complexContent>>
</xs:complexType>>
<!— ========================================================================================= —>>
<xs:element name=”SimpleTexture” type=”SimpleTextureType” substitutionGroup=”_Appearance”/>>
<!— ========================================================================================= —>>
<xs:simpleType name=”TextureTypeType”>>
    <xs:restriction base=”xs:string”>>
        <xs:enumeration value=”specific”/>>
        <xs:enumeration value=”typical”/>>
        <xs:enumeration value=”unknown”/>>
    </xs:restriction>>
</xs:simpleType>>

10.1.  CityGML Core

The CityGML Core module defines the basic concepts and components of the overall CityGML data model. It forms the universal lower bound of the CityGML data model and, thus, is a dependency of all extension modules. Consequently, the core module has to be implemented by any conformant system. Primarily, the core module provides the abstract base classes from which thematic classes within extension modules are (transitively) derived. Besides abstract type definitions, the core also contains non-abstract content, for example basic data types and thematic classes that may be used by more than one extension module. The UML diagram in Figure 27 illustrates CityGML’s core module, for the XML Schema definition see below and Annex A.1.

Figure 27 — UML diagram of CityGML’s core module. The bracketed numbers following the attribute names denote the attribute’s multiplicity: the minimal and maximal number of occurrences of the attribute per object. For example, a name is optional (0) in the class _Feature or may occur multiple times (star symbol), while a _CityObject has none or at most one creationDate. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The base class of all thematic classes within CityGML’s data model is the abstract class _CityObject. _CityObject provides a creation and a termination date for the management of histories of features as well as the possibility to model external references to the same object in other data sets. Furthermore, two qualitative attributes relativeToTerrain and relativeToWater are provided which enable to specify the feature’s location with respect to the terrain and water surface. The possible topological relations are illustrated in Figure 28. Both attributes facilitate simple and efficient queries like for the number of subsurface buildings (entirelyBelowTerrain) without the need for an additional digital terrain model or a model of the water body.

a)

b)

Figure 28 — Topological relations of a CityGML object with respect to a) the terrain and b) the water surface.

_CityObject is a subclass of the GML class _Feature, thus it inherits the metadata property (which can be e.g. information about the lineage, quality aspects, accuracy, local CRS) and name property from the superclass _GML. A _CityObject may have multiple names, which are optionally qualified by a codeSpace.This enables the differentiation between, for example, an official name and a popular name or of names in different languages (cf. the name property of GML objects, Cox et al. 2004). The generalisation property generalizesTo of _CityObject may be used to relate features, which represent the same real-world object in different Levels-of-Detail, i.e. a feature and its generalised counterpart(s). The direction of this relation is from the feature to the corresponding generalised feature.

Thematic classes may have further subclasses with relations, attributes and geometry. Features of the specialized subclasses of _CityObject may be aggregated to a single CityModel, which is a feature collection with optional metadata. Generally, each feature has the attributes class, function, and usage, unless it is stated otherwise. The class attribute can occur only once, while the attributes usage and function can be used multiple times. The class attribute allows for the classification of features beyond the thematic class hierarchy of _CityObject. For example, a building feature is represented by the thematic subclass bldg:Building of _CityObject in the first place (this subclass is defined within CityGML’s Building module, cf. Clause 10.3). A further classification, e.g. as residential or administration building, may then be modelled using the class attribute of the class bldg:Building. The attribute function normally denotes the intended purpose or usage of the object, such as hotel or shopping centre for a building, while the attribute usage normally defines its real or actual usage. Possible values for the attributes class, function, and usage can be specified in code lists which are recommended to be implemented as simple dictionaries following the Simple Dictionary Profile of GML 3.1.1 (cf. Clause 6.6 and Clause 10.14). Annex C provides code lists proposed and maintained by the SIG 3D which contain feasible attribute values and which may be extended or redefined by users.

In addition to thematic content, the core module also provides the concept of implicit geometries as an enhancement of the geometry model of GML3. Since this concept is strongly related to the spatial model of CityGML it has already been introduced in Clause 8.2.

The top level class hierarchy of the thematic model in CityGML is presented in Figure 29. The subclasses of _CityObject comprise the different thematic fields of a city model covered by separate CityGML extension modules: the terrain, buildings, bridges, tunnels, the coverage by land use objects, water bodies, vegetation, generic city objects, city furniture objects, city object groups, and transportation. To indicate the extension module defining a respective subclass of _CityObject, the class names in Figure 29 are preceded by prefixes. Each prefix is associated with one CityGML extension module (see Clause 4.3 and Clause 7 for a list of CityGML’s extension modules and the corresponding prefixes).

Figure 29 — CityGML’s top level class hierarchy. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The classes GenericCityObject and _genericAttribute defined within CityGML’s Generics module (cf. Clause 6.11 and Clause 10.12) allow for modelling and exchanging of 3D objects which are not covered by any other thematic class or which require attributes not represented in CityGML. For example, in the future, sites derived from the abstract class _Site of the core module may be completed by further subclasses like excavation, city wall or embankment. At present, the class GenericCityObject should be used in order to represent and exchange these features. However, the concept of generic city objects and attributes may only be used if appropriate thematic classes or attributes are not provided by any other CityGML module.

If the Generics module is employed, each CityObject may be assigned an arbitrary number of generic attributes in order to represent additional properties of features. For this purpose, the Generics module augments the abstract base class _CityObject by the property element _genericAttribute. The additional property _genericAttribute is injected into _CityObject using CityGML’s Application Domain Extension mechanism (cf. Clause 10.13). By this means, each thematic subclass of _CityObject inherits this property and, thus, the possibility to contain generic attributes. Therefore, the Generics module has a deliberate impact on all CityGML extension modules defining thematic subclasses of _CityObject.

Appearance information about a feature’s surfaces can be represented by the class Appearance provided by CityGML’s Appearance module (cf. Clause 9). In contrast to the other thematic extensions to the core, Appearance is not derived from _CityObject but from the GML class _Feature. _CityObject features and Appearance features may be embraced within a single CityModel feature collection in an arbitrary or even mixed sequence using the cityObjectMember and appearanceMember elements, both being members of the substitution group gml:featureMember (cf. Clause 9 and Clause 10.1.1). Furthermore, feature appearances may be stored inline the _CityObject itself. In order to enable city objects to store appearance information, the Appearance module augments the abstract base class _CityObject by the property element appearance using CityGML’s Application Domain Extension mechanism (cf. Clause 10.13). Consequently, the appearance property is only available for _CityObject and its thematic subclasses if the Appearance module is supported. Therefore, like the Generics module, the Appearance module has a deliberate impact on any other extension module.

For sake of completeness, the class TexturedSurface is also illustrated in Figure 29. This approach of appearance modelling of previous versions of CityGML has been deprecated and is expected to be removed in future CityGML versions. Since the information covered by TexturedSurface can be losslessly converted to the Appearance module, the use of TexturedSurface is strongly discouraged.

XML namespace

The XML namespace of the CityGML Core module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/2.0. Within the XML Schema definition of the core module, this URI is also used to identify the default namespace.

<xs:complexType name=”AbstractCityObjectType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractFeatureType”>
            <xs:sequence>
                <xs:element name=”creationDate” type=”xs:date” minOccurs=”0”/>
                <xs:element name=”terminationDate” type=”xs:date” minOccurs=”0”/>
                <xs:element name=”externalReference” type=”ExternalReferenceType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”generalizesTo” type=”GeneralizationRelationType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”relativeToTerrain” type=”RelativeToTerrainType” minOccurs=”0”/>
                <xs:element name=”relativeToWater” type=”RelativeToWaterType” minOccurs=”0”/>
                <xs:element ref=”_GenericApplicationPropertyOfCityObject” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_CityObject” type=”AbstractCityObjectType” abstract=”true” substitutionGroup=”gml:_Feature”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfCityObject” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”CityModelType”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractFeatureCollectionType”>
            <xs:sequence>
                <xs:element ref=”_GenericApplicationPropertyOfCityModel” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”CityModel” type=”CityModelType” substitutionGroup=”gml:_FeatureCollection”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfCityModel” type=”xs:anyType” abstract=”true”/>

<xs:element name=”cityObjectMember” type=”gml:FeaturePropertyType” substitutionGroup=”gml:featureMember”/>

<xs:complexType name=”AbstractSiteType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”AbstractCityObjectType”>
            <xs:sequence>
                <xs:element ref=”_GenericApplicationPropertyOfSite” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”_Site” type=”AbstractSiteType” abstract=”true” substitutionGroup=”_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfSite” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”GeneralizationRelationType”>
    <xs:sequence minOccurs=”0”>
        <xs:element ref=”_CityObject”/>
    </xs:sequence>
    <xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

<xs:simpleType name=”RelativeToTerrainType”>
    <xs:restriction base=”xs:string”>
        <xs:enumeration value=”entirelyAboveTerrain”/>
        <xs:enumeration value=”substantiallyAboveTerrain”/>
        <xs:enumeration value=”substantiallyAboveAndBelowTerrain”/>
        <xs:enumeration value=”substantiallyBelowTerrain”/>
        <xs:enumeration value=”entirelyBelowTerrain”/>
    </xs:restriction>
</xs:simpleType>
<!— ========================================================================================= —>
<xs:simpleType name=”RelativeToWaterType”>
    <xs:restriction base=”xs:string”>
        <xs:enumeration value=”entirelyAboveWaterSurface”/>
        <xs:enumeration value=”substantiallyAboveWaterSurface”/>
        <xs:enumeration value=”substantiallyAboveAndBelowWaterSurface”/>
        <xs:enumeration value=”substantiallyBelowWaterSurface”/>
        <xs:enumeration value=”entirelyBelowWaterSurface”/>
        <xs:enumeration value=”temporarilyAboveAndBelowWaterSurface”/>
    </xs:restriction>
</xs:simpleType>

<xs:complexType name="ExternalReferenceType">
    <xs:sequence>
        <xs:element name="informationSystem" type="xs:anyURI" minOccurs="0"/>
        <xs:element name="externalObject" type="ExternalObjectReferenceType"/>
    </xs:sequence>
</xs:complexType>
<!-- ========================================================================================== -->
<xs:complexType name="ExternalObjectReferenceType">
    <xs:choice>
        <xs:element name="name" type="xs:string"/>
        <xs:element name="uri" type="xs:anyURI"/>
    </xs:choice>
</xs:complexType>

<xs:complexType name=”AddressPropertyType”>
    <xs:sequence minOccurs=”0”>
        <xs:element ref=”Address”/>
    </xs:sequence>
    <xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>
<!— ========================================================================================== —>
<xs:complexType name=”AddressType”>
    <xs:complexContent>
        <xs:extension base=”gml:AbstractFeatureType”>
            <xs:sequence>
                <xs:element name=”xalAddress” type=”xalAddressPropertyType”/>
                <xs:element name=”multiPoint” type=”gml:MultiPointPropertyType” minOccurs=”0”/>
                <xs:element ref=”_GenericApplicationPropertyOfAddress” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”Address” type=”AddressType” substitutionGroup=”gml:_Feature”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfAddress” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================== —>
<xs:complexType name=”xalAddressPropertyType”>
    <xs:sequence>
        <xs:element ref=”xAL:AddressDetails”/>
    </xs:sequence>
</xs:complexType>

<bldg:Building>
    …
    <bldg:address>
        <core:Address>
            <core:xalAddress>
                <!— Bussardweg 7, 76356 Weingarten, Germany —>
                <xAL:AddressDetails>
                    <xAL:Country>
                        <xAL:CountryName>Germany</xAL:CountryName>
                        <xAL:Locality Type=”City”>
                            <xAL:LocalityName>Weingarten</xAL:LocalityName>
                            <xAL:Thoroughfare Type=”Street”>
                                <xAL:ThoroughfareNumber>7</xAL:ThoroughfareNumber>
                                <xAL:ThoroughfareName>Bussardweg</xAL:ThoroughfareName>
                            </xAL:Thoroughfare>
                            <xAL:PostalCode>
                                <xAL:PostalCodeNumber>76356</xAL:PostalCodeNumber>
                            </xAL:PostalCode>
                        </xAL:Locality>
                    </xAL:Country>
                </xAL:AddressDetails>
            </core:xalAddress>
        </core:Address>
    </bldg:address>
</bldg:Building>

<bldg:Building>
    …
    <bldg:address>
        <core:Address>
            <core:xalAddress>
                <!— 46 Brynmaer Road Battersea LONDON, SW11 4EW United Kingdom —>
                <!— source: http://xml.coverpages.org/xnal.html —>
                <xAL:AddressDetails>
                    <xAL:Country>
                        <xAL:CountryName>United Kingdom</xAL:CountryName>
                        <xAL:Locality Type=”City”>
                            <xAL:LocalityName>LONDON</xAL:LocalityName>
                            <xAL:DependentLocality Type=”District”>
                                <xAL:DependentLocalityName>Battersea</xAL:DependentLocalityName>
                                <xAL:Thoroughfare>
                                    <xAL:ThoroughfareNumber>46</xAL:ThoroughfareNumber>
                                    <xAL:ThoroughfareName>Brynmaer Road</xAL:ThoroughfareName>
                                </xAL:Thoroughfare>
                            </xAL:DependentLocality>
                            <xAL:PostalCode>
                                <xAL:PostalCodeNumber>SW11 4EW</xAL:PostalCodeNumber>
                            </xAL:PostalCode>
                        </xAL:Locality>
                    </xAL:Country>
                </xAL:AddressDetails>
            </core:xalAddress>
        </core:Address>
    </bldg:address>
</bldg:Building>

10.2.  Digital Terrain Model (DTM)

An essential part of a city model is the terrain. The Digital Terrain Model (DTM) of CityGML is provided by the thematic extension module Relief (cf. Clause 7). In CityGML, the terrain is represented by the class ReliefFeature in LOD 0-4 (Figure 30 depicts the UML diagram, for the XML schema definition see Annex A.9). A ReliefFeature consists of one or more entities of the class ReliefComponent. Its validity may be restricted to a certain area defined by an optional validity extent polygon. As ReliefFeature and ReliefComponent are derivatives of _CityObject, the corresponding attributes and relations are inherited. The class ReliefFeature is associated with different concepts of terrain representations which can coexist. The terrain may be specified as a regular raster or grid (RasterRelief), as a TIN (Triangulated Irregular Network, TINReflief), by break lines (BreaklineRelief), or by mass points (MasspointRelief). The four types are implemented by the corresponding GML3 classes: grids by gml:RectifiedGridCoverage, break lines by gml:MultiCurve, mass points by gml:MultiPoint and TINs either by gml:TriangulatedSurface or by gml:Tin. In case of gml:, the triangles are given explicitly while in case of gml:Tin only 3D points are represented, where the triangulation can be reconstructed by standard methods (Delaunay triangulation, cf. Okabe et al. 1992). Break lines are represented by 3D curves. Mass points are simply a set of 3D points.

Figure 30 — UML diagram of the Digital Terrain Model in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Relief module.

In a CityGML dataset the four terrain types may be combined in different ways, yielding a high flexibility. First, each type may be represented in different levels of detail, reflecting different accuracies or resolutions. Second, a part of the terrain can be described by the combination of multiple types, for example by a raster and break lines, or by a TIN and break lines. In this case, the break lines must share the geometry with the triangles. Third, neighboring regions may be represented by different types of terrain models. To facilitate this combination, each terrain object is provided with a spatial attribute denoting its extent of validity (Figure 31). In most cases, the extent of validity of a regular raster dataset corresponds to its bounding box. This validity extent is represented by a 2D footprint polygon, which may have holes. This concept enables, for example, the modelling of a terrain by a coarse grid, where some distinguished regions are represented by a detailed, high-accuracy TIN. The boundaries between both types are given by the extent attributes of the corresponding terrain objects.

Figure 31 — Nested DTMs in CityGML using validity extent polygons (graphic: IGG Uni Bonn).

Accuracy and resolution of the DTM are not necessarily dependent on features of other CityGML extenstion modules such as building models. Hence, there is the possibility to integrate building models with higher LOD to a DTM with lower accuracy or resolution.

This approach interacts with the concept of TerrainIntersectionCurves TIC (cf. Clause 6.5). The TIC can be used like break lines to adjust the DTM to different features such as buildings, bridges, or city furnitures, and hence to ensure a consistent representation of the DTM. If necessary, a retriangulation may have to be processed. A TIC can also be derived by the individual intersection of the DTM and the corresponding feature.

ReliefFeature and its ReliefComponents both have an lod attribute denoting the corresponding level of detail. In most cases, the LOD of a ReliefFeature matches the LOD of its ReliefComponents. However, it is also allowed to specify a ReliefFeature with a high LOD which consists of ReliefComponents where some of them can have a LOD lower than that of the aggregating ReliefFeature. The idea is that, for example, for a LOD3 scene it might be sufficient to use a regular grid in LOD2 with certain higher precision areas defined by ReliefComponents in LOD3. The LOD2 grid and the LOD3 components can easily be integrated using the concept of the validity extent polygon. Therefore, although some of the ReliefComponents would have been classified to a lower LOD, the whole ReliefFeature would be appropriate to use with other LOD3 models which is indicated by setting its lod value to 3.

XML namespace

The XML namespace of the CityGML Relief module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/relief/2.0. Within the XML Schema definition of the Relief module, this URI is also used to identify the default namespace.

<xs:complexType name=”ReliefFeatureType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod” type=”core:integerBetween0and4”/>
				<xs:element name=”reliefComponent” type=”ReliefComponentPropertyType” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfReliefFeature” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”ReliefFeature” type=”ReliefFeatureType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfReliefFeature” type=”xs:anyType” abstract=”true”/>
<!— ========================================================================================= —>
<xs:complexType name=”ReliefComponentPropertyType”>
	<xs:sequence minOccurs=”0”>
		<xs:element ref=”_ReliefComponent”/>
	</xs:sequence>
	<xs:attributeGroup ref=”gml:AssociationAttributeGroup”/>
</xs:complexType>

<xs:complexType name=”AbstractReliefComponentType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod” type=”core:integerBetween0and4”/>
				<xs:element name=”extent” type=”gml:PolygonPropertyType” minOccurs=”0”/>
				<xs:element ref=”_GenericApplicationPropertyOfReliefComponent” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_ReliefComponent” type=”AbstractReliefComponentType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfReliefComponent” type=”xs:anyType” abstract=”true”/>

<xs:complexType name="TINReliefType">
	<xs:complexContent>
		<xs:extension base="AbstractReliefComponentType">
			<xs:sequence>
				<xs:element name="tin" type="tinPropertyType"/>
				<xs:element ref="_GenericApplicationPropertyOfTinRelief" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="TINRelief" type="TINReliefType" substitutionGroup="_ReliefComponent"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfTinRelief" type="xs:anyType" abstract="true"/>
<!-- ========================================================================================= -->
<xs:complexType name="tinPropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="gml:TriangulatedSurface"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

<xs:complexType name="RasterReliefType">
	<xs:complexContent>
		<xs:extension base="AbstractReliefComponentType">
			<xs:sequence>
				<xs:element name="grid" type="gridPropertyType"/>
				<xs:element ref="_GenericApplicationPropertyOfRasterRelief" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="RasterRelief" type="RasterReliefType" substitutionGroup="_ReliefComponent"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfRasterRelief" type="xs:anyType" abstract="true"/>
<!-- ========================================================================================= -->
<!-- ========================================================================================= -->
<xs:complexType name="gridPropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="gml:RectifiedGridCoverage"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="Elevation" type="gml:LengthType" substitutionGroup="gml:_Object"/>

<xs:complexType name="MassPointReliefType">
	<xs:complexContent>
		<xs:extension base="AbstractReliefComponentType">
			<xs:sequence>
				<xs:element name="reliefPoints" type="gml:MultiPointPropertyType"/>
				<xs:element ref="_GenericApplicationPropertyOfMassPointRelief" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="MassPointRelief" type="MassPointReliefType" substitutionGroup="_ReliefComponent"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfMassPointRelief" type="xs:anyType" abstract="true"/>

<xs:complexType name="BreaklineReliefType">
	<xs:complexContent>
		<xs:extension base="AbstractReliefComponentType">
			<xs:sequence>
				<xs:element name="ridgeOrValleyLines" type="gml:MultiCurvePropertyType" minOccurs="0"/>
				<xs:element name="breaklines" type="gml:MultiCurvePropertyType" minOccurs="0"/>
				<xs:element ref="_GenericApplicationPropertyOfBreaklineRelief" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="BreaklineRelief" type="BreaklineReliefType" substitutionGroup="_ReliefComponent"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfBreaklineRelief" type="xs:anyType" abstract="true"/>

10.3.  Building model

The building model is one of the most detailed thematic concepts of CityGML. It allows for the representation of thematic and spatial aspects of buildings and building parts in five levels of detail, LOD0 to LOD4. The building model of CityGML is defined by the thematic extension module Building (cf. Clause 7). Figure 32 provides examples of 3D city and building models in LOD1 — 4.

Figure 32 — Examples for city or building models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left), and LOD4 (lower right) (source: District of Recklinghausen, m-g-h ingenieure+architekten GmbH).

The UML diagram of the building model is depicted in Figure 33, for the XML schema definition see Annex A.4 and below. The pivotal class of the model is _AbstractBuilding, which is a subclass of the thematic class _Site (and transitively of the root class _CityObject). _AbstractBuilding is specialised either to a Building or to a BuildingPart. Since an _AbstractBuilding consists of BuildingParts, which again are _AbstractBuildings, an aggregation hierarchy of arbitrary depth may be realised. As subclass of the root class _CityObject, an _AbstractBuilding inherits all properties from _CityObject like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences (cf. Clause 6.7). Further properties not explicitly covered by _AbstractBuilding may be modelled as generic attributes provided by the CityGML Generics module (cf. Clause 10.12) or using the CityGML Application Domain Extension mechanism (cf. Clause 10.13).

Building complexes, which consist of a number of distinct buildings like a factory site or hospital complex, should be aggregated using the concept of CityObjectGroups (cf. Clause 6.8). The main building of the complex can be denoted by providing “main building” as the role name of the corresponding group member.

Both classes Building and BuildingPart inherit the attributes of _AbstractBuilding: the class of the building, the function (e.g. residential, public, or industry), the usage, the year of construction, the year of demolition, the roof type, the measured height, and the number and individual heights of the storeys above and below ground. This set of parameters is suited for roughly reconstructing the three-dimensional shape of a building and can be provided by cadastral systems. Furthermore, Address features can be assigned to Buildings or BuildingParts.

Figure 33 — UML diagram of CityGML’s building model. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Building module.

The geometric representation and semantic structure of an _AbstractBuilding is shown in Figure 33. The model is successively refined from LOD0 to LOD4. Therefore, not all components of a building model are represented equally in each LOD and not all aggregation levels are allowed in each LOD. In CityGML, all object classes are associated to the LODs with respect to the proposed minimum acquisition criteria for each LOD (cf. Clause 6.2). An object can be represented simultaneously in different LODs by providing distinct geometries for the corresponding LODs.

In LOD0, the building can be represented by horizontal, 3-dimensional surfaces. These can represent the footprint of the building and, separately, the roof edge. This allows the easy integration of 2D data into the model. In many countries these 2D geometries readily exist, for example in cadastral or topographic data holdings. Cadastre data typically depicts the shape of the building on the ground (footprints) and topographic data is often a mixture between footprints and geometries at roof level (roof edges), which are often photogrametrically extracted from area/satellite images or derived from airborne laser data. The building model allows the inclusion of both. In this case large overhanging roofs can be modelled as a preliminary stage to more detailed LOD2 and LOD3 depictions. The surface geometries require 3D coordinates, though it is mandated that the height values of all vertices belonging to the same surface are identical. If 2D geometries are imported into any of these two LOD0 geometries, an appropriate height value for all vertices needs to be chosen. The footprint is typically located at the lowest elevation of the ground surface of the building whereas the roof edge representation should be placed at roof level (e.g., eaves height).

In LOD1, a building model consists of a generalized geometric representation of the outer shell. Optionally, a gml:MultiCurve representing the TerrainIntersectionCurve (cf. Clause 6.5) can be specified. This geometric representation is refined in LOD2 by additional gml:MultiSurface and gml:MultiCurve geometries, used for modelling architectural details like roof overhangs, columns, or antennas. In LOD2 and higher LODs the outer facade of a building can also be differentiated semantically by the classes _BoundarySurface and BuildingInstallation. A _BoundarySurface is a part of the building’s exterior shell with a special function like wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface), outer floor (OuterFloorSurface), outer ceiling (OuterCeilingSurface) or ClosureSurface. The BuildingInstallation class is used for building elements like balconies, chimneys, dormers or outer stairs, strongly affecting the outer appearance of a building. A BuildingInstallation may have the attributes class, function, and usage (cf. Figure 33).

In LOD3, theopenings in _BoundarySurface objects (doors and windows) can be represented as thematic objects. In LOD4, the highest level of resolution, also the interior of a building, composed of several rooms, is represented in the building model by the class Room. This enlargement allows a virtual accessibility of buildings, e.g. for visitor information in a museum (“Location Based Services”), the examination of accommodation standards or the presentation of daylight illumination of a building. The aggregation of rooms according to arbitrary, user defined criteria (e.g. for defining the rooms corresponding to a certain storey) is achieved by employing the general grouping concept provided by CityGML (cf. Clause 10.3.6). Interior installations of a building, i.e. objects within a building which (in contrast to furniture) cannot be moved, are represented by the class IntBuildingInstallation. If an installation is attached to a specific room (e.g. radiators or lamps), they are associated with the Room class, otherwise (e.g. in case of rafters or pipes) with _AbstractBuilding. A Room may have the attributes class, function and usage whose value can be defined in code lists (Clause 10.3.8 and Annex C.1). The class attribute allows a classification of rooms with respect to the stated function, e.g. commercial or private rooms, and occurs only once. The function attribute is intended to express the main purpose of the room, e.g. living room, kitchen. The attribute usage can be used if the way the object is actually used differs from the function. Both attributes can occur multiple times.

The visible surface of a room is represented geometrically as a Solid or MultiSurface. Semantically, the surface can be structured into specialised _BoundarySurfaces, representing floor (FloorSurface), ceiling (CeilingSurface), and interior walls (InteriorWallSurface). Room furniture, like tables and chairs, can be represented in the CityGML building model with the class BuildingFurniture. A BuildingFurniture may have the attributes class, function and usage. Annexes G.1 to G.6 provide example CityGML documents containing a single building model which is subsequently refined from a coarse LOD0 representation up to a semantically rich and geometric-topologically sound LOD4 model including the building interior.

XML namespace

The XML namespace of the CityGML Building module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/building/2.0. Within the XML Schema definition of the Building module, this URI is also used to identify the default namespace.

10.3.1.  Building and building part

<xs:complexType name=”BuildingType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBuildingType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfBuilding” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Building” type=”BuildingType” substitutionGroup=”_AbstractBuilding”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBuilding” type=”xs:anyType” abstract=”true”/>

BuildingType, Building

The Building class is one of the two subclasses of _AbstractBuilding. If a building only consists of one (homogeneous) part, this class shall be used. A building composed of structural segments differing in, for example the number of storeys or the roof type has to be separated into one Building having one or more additional BuildingPart (see Figure 34). The geometry and non-spatial properties of the central part of the building should be represented in the aggregating Building feature.

<xs:complexType name=”BuildingPartType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBuildingType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfBuildingPart” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”BuildingPart” type=”BuildingPartType” substitutionGroup=”_AbstractBuilding”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBuildingPart” type=”xs:anyType” abstract=”true”/>

BuildingPartType, BuildingPart

The class BuildingPart is derived from _AbstractBuilding. It is used to model a structural part of a building (see Figure 34). A BuildingPart object should be uniquely related to exactly one building or building part object.

Figure 34 — Examples of buildings consisting of one and two building parts (source: City of Coburg).

<xs:complexType name=”AbstractBuildingType” abstract=”true”>
    <xs:complexContent>
        <xs:extension base=”core:AbstractSiteType”>
            <xs:sequence>
                <xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
                <xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”yearOfConstruction” type=”xs:gYear” minOccurs=”0”/>
                <xs:element name=”yearOfDemolition” type=”xs:gYear” minOccurs=”0”/>
                <xs:element name=”roofType” type=”gml:CodeType” minOccurs=”0”/>
                <xs:element name=”measuredHeight” type=”gml:LengthType” minOccurs=”0”/>
                <xs:element name=”storeysAboveGround” type=”xs:nonNegativeInteger” minOccurs=”0”/>
                <xs:element name=”storeysBelowGround” type=”xs:nonNegativeInteger” minOccurs=”0”/>
                <xs:element name=”storeyHeightsAboveGround” type=”gml:MeasureOrNullListType” minOccurs=”0”/>
                <xs:element name=”storeyHeightsBelowGround” type=”gml:MeasureOrNullListType” minOccurs=”0”/>
                <xs:element name=”lod0FootPrint” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod0RoofEdge” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod1Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod1MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod1TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”outerBuildingInstallation” type=”BuildingInstallationPropertyType” minOccurs=”0”
                                        maxOccurs=”unbounded”/>
                <xs:element name=”interiorBuildingInstallation” type=”IntBuildingInstallationPropertyType” minOccurs=”0”
                                        maxOccurs=”unbounded”/>
                <xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”lod3Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod3MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod3TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”interiorRoom” type=”InteriorRoomPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”consistsOfBuildingPart” type=”BuildingPartPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”address” type=”core:AddressPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element ref=”_GenericApplicationPropertyOfAbstractBuilding” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_AbstractBuilding” type=”AbstractBuildingType” abstract=”true” substitutionGroup=”core:_Site”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfAbstractBuilding” type=”xs:anyType” abstract=”true”/>

AbstractBuildingType, _AbstractBuilding

The abstract class _AbstractBuilding contains properties for building attributes, purely geometric representations, and geometric/semantic representations of the building or building part in different levels of detail. The attributes describe:

1. The classification of the building or building part (class), the different intended usages (function), and the different actual usages (usage). The permitted values for these attributes can be specified in code lists.

2. The year of construction (yearOfConstruction) and the year of demolition (yearOfDemolition) of the building or building part. These attributes can be used to describe the chronology of the building development within a city model. The points of time refer to real world time.

3. The roof type of the building or building part (roofType). The permitted values for this attribute can be specified in a code list.

4. The measured relative height (measuredHeight) of the building or building part.

5. The number of storeys above (storeyAboveGround) and below (storeyBelowGround) ground level.

6. The list of storey heights above (storeyHeightsAboveGround) and below (storeyHeightsBelowGround) ground level. The first value in a list denotes the height of the nearest storey wrt. to the ground level and last value the height of the farthest.

Spanning the different levels of detail, the building model differs in the complexity and granularity of the geometric representation and the thematic structuring of the model into components with a special semantic meaning. This is illustrated in Figure 35 and Figure 36, showing the same building in five different LODs. The class _AbstractBuilding has a number of properties which are associated with certain LODs.

Figure 35 — The two possibilities of modeling a building in LOD0 using horizontal 3D surfaces. On the left, the building footprint (lod0FootPrint) is shown (cyan)which denotes the shape of the building on the ground. The corresponding surface representation is located at ground level.On the right, the lod0RoofEgde representation is illustrated (cyan) which results from a horizontal projection of the building’s roof and which is located at the eaves height (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

Figure 36 — Building model in LOD1 — LOD4 (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

Table 5 shows the correspondence of the different geometric and semantic themes of the building model to LODs. In LOD1 — 4, the volume of a building can be expressed by a gml:Solid geometry and/or a gml:MultiSurface geometry. The definition of a 3D Terrain Intersection Curve (TIC), used to integrate buildings from different sources with the Digital Terrain Model, is also possible in LOD1 - 4. The TIC can — but does not have to — build closed rings around the building or building parts.

In LOD0 (cf. Figure 35) the building is represented by horizontal surfaces describing the footprint and the roof edge.

In LOD1 (cf. Figure 36), the different structural entities of a building are aggregated to a simple block and not differentiated in detail. The volumetric and surface parts of the exterior building shell are identical and only one of the corresponding properties (lod1Solid or lod1MultiSurface) must be used.

In LOD2 and higher levels of detail, the exterior shell of a building is not only represented geometrically as gml:Solid geometry and/or a gml:MultiSurface geometry, but it can also be composed of semantic objects. The base class for all objects semantically structuring the building shell is _BoundarySurface (cf. Clause 10.3.2), which is associated with a gml:MultiSurface geometry. If in a building model there is both a geometric representation of the exterior shell as volume or surface model and a semantic representation by means of thematic _BoundarySurfaces, the geometric representation must not explicitly define the geometry, but has to reference the corresponding geometry components of the gml:MultiSurface of the _BoundarySurface elements.

Table 5 — Semantic themes of the class _AbstractBuilding.

Geometric / semantic theme	Property type	LOD0	LOD1	LOD2	LOD3	LOD4
Building footprint and roof edge	gml:MultiSurfaceType	•
Volume part of the building shell	gml:SolidType		•	•	•	•
Surface part of the building shell	gml:MultiSurfaceType		•	•	•	•
Terrain intersection curve	gml:MultiCurveType		•	•	•	•
Curve part of the building shell	gml:MultiCurveType			•	•	•
Building parts	BuildingPartType		•	•	•	•
Boundary surfaces (Clause 10.3.3)	AbstractBoundarySurfaceType			•	•	•
Outer building installations (Clause 10.3.2)	BuildingInstallationType			•	•	•
Openings (Clause 10.3.4)	AbstractOpeningType				•	•
Rooms (Clause 10.3.5)	RoomType					•
Interior building installations (Clause 10.3.5)	IntBuildingInstallationType					•

Apart from BuildingParts, smaller features of the building (“outer building installations”) can also strongly affect the building characteristic. These features are modelled by the class BuildingInstallation (cf. Clause 10.3.2). Typical candidates for this class are chimneys (see. Figure 36), dormers (see Figure 34), balconies, outer stairs, or antennas. BuildingInstallations may only be included in LOD2 models, if their extents exceed the proposed minimum dimensions as specified in Clause 6.2. For the geometrical representation of the class BuildingInstallation, an arbitrary geometry object from the GML subset shown in Figure 14 can be used.

The class _AbstractBuilding has no additional properties for LOD3. Besides the higher requirements on geometric precision and smaller minimum dimensions, the main difference of LOD2 and LOD3 buildings concerns the class _BoundarySurface (cf. Clause 10.3.3). In LOD3, openings in a building corresponding with windows or doors (see Figure 36) are modelled by the abstract class _Opening and the derived subclasses Window and Door (cf. Clause 10.3.4).

With respect to the exterior building shell, the LOD4 data model is identical to that of LOD3. But LOD4 provides the possibility to model the interior structure of a building with the classes IntBuildingInstallation and Room (cf. Clause 10.3.5).

Each Building or BuildingPart feature may be assigned zero or more addresses using the address property. The corresponding AddressPropertyType is defined within the CityGML core module (cf. Clause 10.1.4).

<xs:complexType name="BuildingInstallationType">
	<xs:complexContent>
		<xs:extension base="core:AbstractCityObjectType">
			<xs:sequence>
				<xs:element name="class" type="gml:CodeType" minOccurs="0"/>
				<xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
				<xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
				<xs:element name="lod2Geometry" type="gml:GeometryPropertyType" minOccurs="0"/>
				<xs:element name="lod3Geometry" type="gml:GeometryPropertyType" minOccurs="0"/>
				<xs:element name="lod4Geometry" type="gml:GeometryPropertyType" minOccurs="0"/>
				<xs:element name="lod2ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/>
				<xs:element name="lod3ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/>
				<xs:element name="lod4ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/>
				<xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/>
				<xs:element ref="_GenericApplicationPropertyOfBuildingInstallation" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ========================================================================================= -->
<xs:element name="BuildingInstallation" type="BuildingInstallationType" substitutionGroup="core:_CityObject"/>
<!-- ========================================================================================= -->
<xs:element name="_GenericApplicationPropertyOfBuildingInstallation" type="xs:anyType" abstract="true"/>

10.3.3.  Boundary surfaces

<xs:complexType name=”AbstractBoundarySurfaceType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”opening” type=”OpeningPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfBoundarySurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”_BoundarySurface” type=”AbstractBoundarySurfaceType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfBoundarySurface” type=”xs:anyType” abstract=”true”/>

AbstractBoundarySurfaceType, _BoundarySurface

_BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a building as well as the visible surfaces of rooms and both outer and interior building installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived. The thematic classification of building surfaces is illustrated in Figure 37 (outer building shell) and Figure 38 (additional interior surfaces) and subsequently specified.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry.

In LOD3 and LOD4, a _BoundarySurface may contain _Openings (cf. Clause 10.3.4) like doors and windows. If the geometric location of _Openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these _Openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door, a Window, or a ClosureSurface, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an Opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the Opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface (Figure 38 on the right).

Figure 37 — Examples of the classification of _BoundarySurfaces of the outer building shell (source: Karlsruhe Institute of Technology (KIT))

Figure 38 — Classification of BoundarySurfaces (left), in particular for Openings (right) (graphic: IGG Uni Bonn).

<xs:complexType name=”GroundSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfGroundSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”GroundSurface” type=”GroundSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfGroundSurface” type=”xs:anyType” abstract=”true”/>

GroundSurfaceType, GroundSurface

The ground plate of a building or building part is modelled by the class GroundSurface. The polygon defining the ground plate is congruent with the building’s footprint. However, the surface normal of the ground plate is pointing downwards.

<xs:complexType name=”OuterCeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterCeilingSurface” type=”OuterCeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterCeilingSurface” type=”xs:anyType” abstract=”true”/>

OuterCeilingSurfaceType, OuterCeilingSurface

A mostly horizontal surface belonging to the outer building shell and having the orientation pointing downwards can be modeled as an OuterCeilingSurface. Examples are the visible part of the ceiling of a loggia or the ceiling of a passage.

<xs:complexType name=”WallSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfWallSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”WallSurface” type=”WallSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfWallSurface” type=”xs:anyType” abstract=”true”/>

WallSurfaceType, WallSurface

All parts of the building facade belonging to the outer building shell can be modelled by the class WallSurface.

<xs:complexType name=”OuterFloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterFloorSurface” type=”OuterFloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterFloorSurface” type=”xs:anyType” abstract=”true”/>

OuterFloorSurfaceType, OuterFloorSurface

A mostly horizontal surface belonging to the outer building shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface. An example is the floor of a loggia.

<xs:complexType name=”RoofSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfRoofSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”RoofSurface” type=”RoofSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfRoofSurface” type=”xs:anyType” abstract=”true”/>

RoofSurfaceType, RoofSurface

The major roof parts of a building or building part are expressed by the class RoofSurface. Secondary parts of a roof with a specific semantic meaning like dormers or chimneys should be modelled as BuildingInstallation.

<xs:complexType name=”ClosureSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfClosureSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”ClosureSurface” type=”ClosureSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfClosureSurface” type=”xs:anyType” abstract=”true”/>

ClosureSurfaceType, ClosureSurface

An opening in a building not filled by a door or window can be sealed by a virtual surface called ClosureSurface (cf. Clause 6.4). Hence, buildings with open sides like a barn or a hangar, can be virtually closed in order to be able to compute their volume. ClosureSurfaces are also used in the interior building model. If two rooms with a different function (e.g. kitchen and living room) are directly connected without a separating door, a ClosureSurface should be used to separate or connect the volumes of both rooms.

<xs:complexType name=”FloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”FloorSurface” type=”FloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfFloorSurface” type=”xs:anyType” abstract=”true”/>

FloorSurfaceType, FloorSurface

The class FloorSurface must only be used in the LOD4 interior building model for modelling the floor of a room.

<xs:complexType name=”FloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”FloorSurface” type=”FloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfFloorSurface” type=”xs:anyType” abstract=”true”/>

InteriorWallSurfaceType, InteriorWallSurface

The class InteriorWallSurface must only be used in the LOD4 interior building model for modelling the visible surfaces of the room walls.

<xs:complexType name=”CeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”CeilingSurface” type=”CeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfCeilingSurface” type=”xs:anyType” abstract=”true”/>

CeilingSurfaceType, CeilingSurface

The class CeilingSurface must only be used in the LOD4 interior building model for modelling the ceiling of a room.

<xs:complexType name=”CeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”CeilingSurface” type=”CeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfCeilingSurface” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”WindowType”>
	<xs:complexContent>
		<xs:extension base=”AbstractOpeningType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfWindow” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Window” type=”WindowType” substitutionGroup=”_Opening”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfWindow” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”DoorType”>
	<xs:complexContent>
		<xs:extension base=”AbstractOpeningType”>
			<xs:sequence>
				<xs:element name=”address” type=”core:AddressPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfDoor” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Door” type=”DoorType” substitutionGroup=”_Opening”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfDoor” type=”xs:anyType” abstract=”true”/>

10.3.5.  Building interior

<xs:complexType name=”RoomType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”interiorFurniture” type=”InteriorFurniturePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”roomInstallation” type=”IntBuildingInstallationPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfRoom” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Room” type=”RoomType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfRoom” type=”xs:anyType” abstract=”true”/>

RoomType, Room

A Room is a semantic object for modelling the free space inside a building and should be uniquely related to exactly one building or building part object. It should be closed (if necessary by using ClosureSurfaces) and the geometry normally will be described by a solid (lod4Solid). However, if the topological correctness of the boundary cannot be guaranteed, the geometry can alternatively be given as a MultiSurface (lod4MultiSurface). The surface normals of the outer shell of a GML solid must point outwards. This is important to consider when Room surfaces should be assigned Appearances. In this case, textures and colors must be placed on the backside of the corresponding surfaces in order to be visible from the inside of the room.

In addition to the geometrical representation, different parts of the visible surface of a room can be modelled by specialised BoundarySurfaces (FloorSurface, CeilingSurface, InteriorWallSurface, and ClosureSurface cf. Clause 10.3.3).

A special task is the modelling of passages between adjacent rooms. The room solids are topologically connected by the surfaces representing hatches, doors or closure surfaces that seal open doorways. Rooms are defined as being adjacent, if they have common _Openings or ClosureSurfaces. The surface that represents the opening geometrically is part of the boundaries of the solids of both rooms, or the opening is referenced by both rooms on the semantic level. This adjacency implies an accessibility graph, which can be employed to determine the spread of e.g. smoke or gas, but which can also be used to compute escape routes using classical shortest path algorithms (see Figure 39).

Figure 39 — Accessibility graph derived from topological adjacencies of room surfaces (graphic: IGG Uni Bonn).

<xs:complexType name=”BuildingFurnitureType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element ref=”_GenericApplicationPropertyOfBuildingFurniture” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”BuildingFurniture” type=”BuildingFurnitureType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBuildingFurniture” type=”xs:anyType” abstract=”true”/>

BuildingFurnitureType, BuildingFurniture

Rooms may have BuildingFurnitures and IntBuildingInstallations. A BuildingFurniture is a movable part of a room, such as a chair or furniture. A BuildingFurniture object should be uniquely related to exactly one room object. Its geometry may be represented by an explicit geometry or an ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype building furniture is stored only once in a local coordinate system and referenced by other building furniture features (see Clause 8.2).

<xs:complexType name=”IntBuildingInstallationType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfIntBuildingInstallation” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”IntBuildingInstallation” type=”IntBuildingInstallationType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfIntBuildingInstallation” type=”xs:anyType” abstract=”true”/>

IntBuildingInstallationType, IntBuildingInstallation

An IntBuildingInstallation is an object inside a building with a specialised function or semantic meaning. In contrast to BuildingFurniture, IntBuildingInstallations are permanently attached to the building structure and cannot be moved. Typical examples are interior stairs, railings, radiators or pipes. Objects of the class IntBuildingInstallation can either be associated with a room (class Room), or with the complete building / building part (class _AbstractBuilding, cf. Clause 10.3.1). However, they should be uniquely related to exactly one room or one building / building part object. An IntBuildingInstallation optionally has attributes class, function and usage. The attribute class, which can only occur once, represents a general classification of the internal building component. With the attributes function and usage, nominal and real functions of a building installation can be described. For all three attributes the list of feasible values can be specified in a code list. For the geometrical representation of an IntBuildingInstallation, an arbitrary geometry object from the GML subset shown in Figure 14 can be used. Alternatively, the geometry may be given as ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype interior building installation is stored only once in a local coordinate system and referenced by other interior building installation features (see Clause 8.2). The visible surfaces of an interior building installation can be semantically classified using the concept of boundary surfaces (cf. Clause 10.3.3).

10.3.7.  Examples

The LOD1 model of the Campus North of the Karlruhe Institute of Technology (KIT) shown in Figure 40 consists of 596 buildings and 187 building parts. The footprint geometries of the buildings are taken from a cadastral information system and extruded by a given height. Buildings with a unique identifier and a single height value are modeled as one building (bldg:Building). Buildings having a unique identifier but different height values are modeled as one building (bldg:Building) with one or more building parts (bldg:BuildingPart). Both buildings and building parts have solid geometries and their height values are additionally represented as thematic attribute (bldg:measuredHeight). Figure 40 shows an aerial photograph of the KIT Campus North (left) and the CityGML LOD1 model (right).

Figure 40 — LOD1 model of the KIT Campus North (source: Karlsruhe Institute of Technology (KIT)).

An example for a fully textured LOD2 building model is given in Figure 41 which shows the Bernhardus church located in the city of Karlsruhe, Germany. On the left side of Figure 41, a photograph of the church in real world is shown whereas the CityGML building model of the church with photorealistic textures is illustrated on the right. The model is bounded by a ground surface, several wall and roof surfaces. The railing above the church clock is modeled as a building installation (BuildingInstallation).

Figure 41 — Textured LOD2 model of the Bernhardus church in Karlsruhe (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

The model shown in Figure 42 was derived from a 3D CAD model generated during the planning phase of the building. On the left side of Figure 42, the building is shown whereas on the right side the LOD3 model is presented. The building itself is bounded by wall surfaces, roof surfaces and a ground surface. Doors and windows are modeled including reveals. According to the cadaster data, the car port next to the building is not part of the building. Therefore the car port, the balcony and the chimney are modeled as building installations (BuildingInstallation). The model also contains the terrain intersection curve (lod3TerrainIntersection) as planned by the architect.

In order to determine the volume of the building, the geometries of all boundary surfaces, including doors and windows, are referenced by the building solid (lod3Solid) using the XLink mechanism. Consequently, the roof surfaces are split into surfaces representing the roof itself and surfaces representing the roof overhangs.

Figure 42 — Example of a building modeled in the Level of Detail 3. The chimney, the balcony and the car port are modeled as building installations (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

10.4.  Tunnel model

The tunnel model is closely related to the building model. It supports the representation of thematic and spatial aspects of tunnels and tunnel parts in four levels of detail, LOD1 to LOD4. The tunnel model of CityGML is defined by the thematic extension module Tunnel (cf. Clause 7). Figure 43 provides examples of tunnel models for each LOD.

Figure 43 — Examples for tunnel models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left) and LOD4 (lower right) (source: Google 3D warehouse).

The UML diagram of the tunnel model is shown in Figure 44. The XML schema definition is attached in Annex A.11. The pivotal class of the model is _AbstractTunnel, which is a subclass of the thematic class _Site (and transitively of the root class _CityObject). _AbstractTunnel is specialized either to a Tunnel or to a TunnelPart. Since an _AbstractTunnel consists of TunnelParts, which again are AbstractTunnels, an aggregation hierarchy of arbitrary depth may be realized. As subclass of the root class _CityObject, an AbstractTunnel inherits all properties from _CityObject like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences (cf. Clause 6.7). Further properties not explicitly covered by _AbstractTunnel may be modelled as generic attributes provided by the CityGML Generics module (cf. Clause 10.12) or using the CityGML Application Domain Extension mechanism (cf. Clause 10.13).

Both classes Tunnel and TunnelPart inherit the attributes of _AbstractTunnel: the class of the tunnel, the function, the usage, the year of construction and the year of demolition. In contrast to _AbstractBuilding, Address features cannot be assigned to _AbstractTunnel.

Figure 44 — UML diagram of CityGML’s tunnel model. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Tunnel module.

The geometric representation and semantic structure of an _AbstractTunnel is shown in Figure 44. The model is successively refined from LOD1 to LOD4. Therefore, not all components of a tunnel model are represented equally in each LOD and not all aggregation levels are allowed in each LOD. In CityGML, all object classes are associated to the LODs with respect to the proposed minimum acquisition criteria for each LOD (cf. Clause 6.2). An object can be represented simultaneously in different LODs by providing distinct geometries for the corresponding LODs.

Similar to the building and brigde models (cf. Clause 10.3 and Clause 10.5), only the outer shell of a tunnel is represented in LOD1 — 3, which is composed of the tunnel’s boundary surfaces to the surrounding earth, water, or outdoor air. The interior of a tunnel may only be modeled in LOD4. Although the interior built environment is especially relevant for subsurface objects like tunnels or underground buildings, CityGML employs a consistent LOD concept for all thematic modules. If, in contrast, the representation of the interior of subsurface objects would be possible in all LODs, the LOD concept for subsurface objects would have to substantially differ from the LOD concept for aboveground objects. This would require the precise definition of a “transition surface” which delimits the scope of both LOD concepts. Furthermore, features being partially above and below ground would have to be split into an above-ground part (modeled according to the aboveground LOD concept) and a subsurface part (modeled according to the subsurface LOD concept). However, such a splitting violates the CityGML concept of unity of features and would not be feasible in many cases where the transition between above and below ground is often not precisely known or depends on (the LOD of) the terrain model. Hence, CityGML applies a single and consistent LOD concept to both aboveground and subsurface objects. As a consequence, penetrations between a tunnel and objects inside this tunnel (e.g., roads and railways) may occur in LOD1 — 3.

In LOD1, a tunnel model consists of a geometric representation of the tunnel volume. Optionally, a MultiCurve representing the TerrainIntersectionCurve (cf. Clause 6.5) can be specified. The geometric representation is refined in LOD2 by additional MultiSurface and MultiCurve geometries.

In LOD2 and higher LODs the outer structure of a tunnel can also be differentiated semantically by the classes _BoundarySurface and TunnelInstallation. A boundary surface is a part of the tunnel’s exterior shell with a special function like wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface), outer floor (OuterFloorSurface), outer ceiling (OuterCeilingSurface) or ClosureSurface. The TunnelInstallation class is used for tunnel elements like outer stairs, strongly affecting the outer appearance of a tunnel. A TunnelInstallation may have the attributes class, function and usage (see Figure 44).

In LOD3, the openings in _BoundarySurface objects (doors and windows) can be represented as thematic objects.

In LOD4, the highest level of resolution, also the interior of a tunnel, composed of several hollow spaces, is represented in the tunnel model by the class HollowSpace. This enlargement allows a virtual accessibility of tunnels, e.g. for driving through a tunnel, for simulating disaster management or for presenting the light illumination within a tunnel. The aggregation of hollow spaces according to arbitrary, user defined criteria (e.g. for defining the hollow spaces corresponding to horizontal or vertical sections) is achieved by employing the general grouping concept provided by CityGML (cf. Clause 10.11). Interior installations of a tunnel, i.e. objects within a tunnel which (in contrast to furniture) cannot be moved, are represented by the class IntTunnelInstallation. If an installation is attached to a specific hollow space (e.g. lamps, ventilator), they are associated with the HollowSpace class, otherwise (e.g. pipes) with _AbstractTunnel. A HollowSpace may have the attributes class, function and usage whose possible values can be enumerated in code lists (Clause 10.4.7, Annex C). The class attribute allows a general classification of hollow spaces, e.g. commercial or private rooms, and occurs only once. The function attribute is intended to express the main purpose of the hollow space, e.g. control area, installation space, storage space. The attribute usage can be used if the way the object is actually used differs from the function. Both attributes can occur multiple times.

The visible surface of a hollow space is represented geometrically as a Solid or MultiSurface. Semantically, the surface can be structured into specialised _BoundarySurfaces, representing floor (FloorSurface), ceiling (CeilingSurface), and interior walls (InteriorWallSurface). Hollow space furniture, like movable equipment in control areas, can be represented in the CityGML tunnel model with the class TunnelFurniture. A TunnelFurniture may have the attributes class, function and usage.

XML namespace

The XML namespace of the CityGML Tunnel module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/tunnel/2.0. Within the XML Schema definition of the Tunnel module, this URI is also used to identify the default namespace.

10.4.1.  Tunnel and tunnel part

<xs:complexType name=”TunnelType”>
	<xs:complexContent>
		<xs:extension base=”AbstractTunnelType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfTunnel” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”Tunnel” type=”TunnelType” substitutionGroup=”_AbstractTunnel”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfTunnel” type=”xs:anyType” abstract=”true”/>

TunnelType, Tunnel

The Tunnel class is one of the two subclasses of _AbstractTunnel. If a tunnel only consists of one (homogeneous) part, this class shall be used. A tunnel composed of structural segments, for example tunnel entrance and subway, has to be separated into one tunnel having one or more additional TunnelPart (see Figure 45). The geometry and non-spatial properties of the central part of the tunnel should be represented in the aggregating Tunnel feature.

<xs:complexType name=”TunnelPartType”>
	<xs:complexContent>
		<xs:extension base=”AbstractTunnelType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfTunnelPart” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”TunnelPart” type=”TunnelPartType” substitutionGroup=”_AbstractTunnel”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfTunnelPart” type=”xs:anyType” abstract=”true”/>

TunnelPartType, TunnelPart

If sections of a tunnel differ in geometry and / or attributes, the tunnel can be separated into parts (see Figure 45). Like Tunnel, the class TunnelPart is derived from _AbstractTunnel and inherites all attributes of _AbstractTunnel. A TunnelPart object should be uniquely related to exactly one tunnel or tunnel part object.

Figure 45 — Example of a tunnel modeled with two tunnel parts (source: Helmut Stracke).

<xs:complexType name=”AbstractTunnelType”>
    <xs:complexContent>
        <xs:extension base=”core:AbstractSiteType”>
            <xs:sequence>
                <xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
                <xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”yearOfConstruction” type=”xs:gYear” minOccurs=”0”/>
                <xs:element name=”yearOfDemolition” type=”xs:gYear” minOccurs=”0”/>
                <xs:element name=”lod1Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod1MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod1TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod2TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”outerTunnelInstallation” type=”TunnelInstallationPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”interiorTunnelInstallation” type=”IntTunnelInstallationPropertyType” minOccurs=”0”
                                        maxOccurs=”unbounded”/>
                <xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”lod3Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod3MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod3TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
                <xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”lod4TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
                <xs:element name=”interiorHollowSpace” type=”InteriorHollowSpacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element name=”consistsOfTunnelPart” type=”TunnelPartPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
                <xs:element ref=”_GenericApplicationPropertyOfAbstractTunnel” minOccurs=”0” maxOccurs=”unbounded”/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”_AbstractTunnel” type=”AbstractTunnelType” abstract=”true” substitutionGroup=”core:_Site”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfAbstractTunnel” type=”xs:anyType” abstract=”true”/>

AbstractTunnelType, _AbstractTunnel

The abstract class _AbstractTunnel contains properties for tunnel attributes, purely geometric representations, and geometric/semantic representations of the tunnel or tunnel part in different levels of detail. The attributes describe:

1. The classification of the tunnel or tunnel part (class), the different functions (function), and the usage (usage). The type of these attributes is gml:CodeType and the values can be specified in separate code lists.

2. The year of construction (yearOfConstruction) and the year of demolition (yearOfDemolition) of the tunnel or tunnel part. The yearOfConstruction is the year of completion of the tunnel. The yearOfDemolition is the year when the demolition of the tunnel was completed. The date (year) refer to real world time (e.g. 2011).

Spanning the different levels of detail, the tunnel model differs in the complexity and granularity of the geometric representation and the thematic structuring of the model into components with a special semantic meaning. This is illustrated in Figure 46, showing the same tunnel in four different LODs. Some properties of the class _AbstractTunnel are also associated with certain LODs.

Figure 46 — Tunnel model in LOD1 — LOD4 (source: Karlsruhe Institute of Technology (KIT)).

Table 6 shows the correspondence of the different geometric and semantic themes of the tunnel model to LODs. In each LOD, the volume of a tunnel can be expressed by a gml:Solid geometry and/or a gml:MultiSurface geometry. The definition of a 3D Terrain Intersection Curve (TIC), used to integrate tunnels from different sources with the Digital Terrain Model, is also possible in all LODs. The TIC can — but does not have to — build closed rings around the tunnel or tunnel parts.

Table 6 — Semantic themes of the class _AbstractTunnel.

Geometric / semantic theme	Property type	LOD1	LOD2	LOD3	LOD4
Volume part of the tunnel shell	gml:SolidType	•	•	•	•
Surface part of the tunnel shell	gml:MultiSurfaceType	•	•	•	•
Terrain intersection curve	gml:MultiCurveType	•	•	•	•
Curve part of the tunnel shell	gml:MultiCurveType		•	•	•
Tunnel parts	TunnelPartType	•	•	•	•
Boundary surfaces (Clause 10.4.3)	AbstractBoundarySurfaceType		•	•	•
Outer tunnel installations (Clause 10.4.2)	TunnelInstallationType		•	•	•
Openings	AbstractOpeningType			•	•
Hollow spaces (Clause 10.4.5)	HollowSpaceType				•
Interior tunnel installations	IntTunnelInstallationType				•

10.4.3.  Boundary surfaces

<xs:complexType name=”AbstractBoundarySurfaceType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”opening” type=”OpeningPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfBoundarySurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”_BoundarySurface” type=”AbstractBoundarySurfaceType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfBoundarySurface” type=”xs:anyType” abstract=”true”/>

_BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a tunnel as well as the visible surface of hollow spaces and both outer and interior tunnel installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived. The thematic classification of tunnel surfaces is illustrated in Figure 47 for different types of tunnel cross sections and are specified below.

Figure 47 — Examples for the use of boundary surfaces for tunnels with different cross sections. WallSurface, RoofSurface, GroundSurface, OuterCeilingSurface and OuterFloorSurface are available in LOD2 - 4, whereas InteriorWallSurface, FloorSurface and CeilingSurface may only be used in LOD4 to model the interior boundary surfaces of a hollow space.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry. Starting from LOD3, a _BoundarySurface may contain _Openings (cf. Clause 10.4.4) like doors and windows. If the geometric location of openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door or a Window, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface (cf. right part of Figure 38 for the same situation in a building model).

<xs:complexType name=”GroundSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfGroundSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”GroundSurface” type=”GroundSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfGroundSurface” type=”xs:anyType” abstract=”true”/>

GroundSurfaceType, GroundSurface

The ground plate of a tunnel or tunnel part is modelled by the class GroundSurface. Usually a GroundSurface is a boundary surface between the tunnel and the surrounding earth (soil, rock etc.) or water.

<xs:complexType name=”OuterCeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterCeilingSurface” type=”OuterCeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterCeilingSurface” type=”xs:anyType” abstract=”true”/>

OuterCeilingSurfaceType, OuterCeilingSurface

A mostly horizontal surface belonging to the outer tunnel shell and with the orientation pointing downwards can be modeled as an OuterCeilingSurface. Examples are the visible part of an avalanche protector or the boundary surface between the tunnel and the surrounding earth or water.

<xs:complexType name=”WallSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfWallSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”WallSurface” type=”WallSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfWallSurface” type=”xs:anyType” abstract=”true”/>

WallSurfaceType, WallSurface

All parts of the tunnel facade belonging to the outer tunnel shell can be modelled by the class WallSurface. Usually a WallSurface is a boundary surface between the tunnel and the surrounding earth (soil, rock etc.) or water.

<xs:complexType name=”OuterFloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterFloorSurface” type=”OuterFloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterFloorSurface” type=”xs:anyType” abstract=”true”/>

OuterFloorSurfaceType, OuterFloorSurface

A mostly horizontal surface belonging to the outer tunnel shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface.

<xs:complexType name=”RoofSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfRoofSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”RoofSurface” type=”RoofSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfRoofSurface” type=”xs:anyType” abstract=”true”/>

RoofSurfaceType, RoofSurface

Boundary surfaces belonging to the outer tunnel shell and with the main purpose to protect the tunnel from above are expressed by the class RoofSurface. The orientation of these boundaries is mainly pointing upwards.

<xs:complexType name=”ClosureSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfClosureSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”ClosureSurface” type=”ClosureSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfClosureSurface” type=”xs:anyType” abstract=”true”/>

ClosureSurfaceType, ClosureSurface

Openings in tunnels or hollow spaces not filled by a door or a window can be sealed by a virtual surface called ClosureSurface (cf. Clause 6.4). For example, the doorways of tunnels can be modelled as ClosureSurface.

<xs:complexType name=”FloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”FloorSurface” type=”FloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfFloorSurface” type=”xs:anyType” abstract=”true”/>

FloorSurfaceType, FloorSurface

The class FloorSurface must only be used in the LOD4 interior tunnel model for modelling the floor of hollow spaces.

<xs:complexType name=”InteriorWallSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfInteriorWallSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”InteriorWallSurface” type=”InteriorWallSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfInteriorWallSurface” type=”xs:anyType” abstract=”true”/>

InteriorWallSurfaceType, InteriorWallSurface

The class InteriorWallSurface is only allowed to be used in the LOD4 interior tunnel model for modelling the visible wall surfaces of hollow spaces.

<xs:complexType name=”CeilingSurfaceType”>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”CeilingSurface” type=”CeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfCeilingSurface” type=”xs:anyType” abstract=”true”/>

CeilingSurfaceType, CeilingSurface

The class CeilingSurface is only allowed to be used in the LOD4 interior tunnel model for modelling the ceiling of hollow spaces.

<xs:complexType name=”AbstractOpeningType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element ref=”_GenericApplicationPropertyOfOpening” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_Opening” type=”AbstractOpeningType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfOpening” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”AbstractOpeningType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element ref=”_GenericApplicationPropertyOfOpening” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_Opening” type=”AbstractOpeningType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfOpening” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”DoorType”>
	<xs:complexContent>
		<xs:extension base=”AbstractOpeningType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfDoor” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Door” type=”DoorType” substitutionGroup=”_Opening”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfDoor” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”HollowSpaceType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”interiorFurniture” type=”InteriorFurniturePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”hollowSpaceInstallation” type=”IntTunnelInstallationPropertyType” minOccurs=”0”
										maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfHollowSpace” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”HollowSpace” type=”HollowSpaceType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfHollowSpace” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”TunnelFurnitureType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element ref=”_GenericApplicationPropertyOfTunnelFurniture” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”TunnelFurniture” type=”TunnelFurnitureType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfTunnelFurniture” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”IntTunnelInstallationType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfIntTunnelInstallation” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”IntTunnelInstallation” type=”IntTunnelInstallationType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfIntTunnelInstallation” type=”xs:anyType” abstract=”true”/>

10.4.6.  Examples

The example in Figure 48 shows a pedestrian underpass in the city centre of Karlsruhe, Germany. On the left side of Figure 48, a photo illustrates the real world situation. Both entrances of the underpass are marked in the photo by dashed rectangles. On the right side of the figure, the CityGML tunnel model is shown. The terrain surrounding the tunnel has been virtually cut out of model in order to visualize the entire tunnel with its subsurface body. The same underpass is illustrated in Figure 49 from a different perspective. The camera is positioned in front of the left entrance (black dashed rectangle in Figure 48) and pointing in the direction of the right entrance (white dashed rectangle in Figure 48). On the right side of Figure 49, the tunnel model is shown from the same perspective. Again holes are cut in the terrain surface in order to make the subsurface part of the tunnel visible. An LOD1 representation of the nearby buildings is shown in the background of the model.

Figure 48 — Example of a tunnel modeled in LOD3 (real situation on the left side; CityGML model on the right side) (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

Figure 49 — The same LOD3 tunnel shown from a different perspective. The camera is positioned in front of the left entrance and pointing in the direction of the right entrance. (real situation on the left side; CityGML model on the right side). The model on the right also includes an LOD1 representation of the nearby buildings in the background (painted in light brown) (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

The model is subdivided into one Tunnel (the actual underpass) and two TunnelParts (both entrances). The tunnel and tunnel parts are bounded by GroundSurface, WallSurface, RoofSurface. ClosureSurface objects are used to virtually seal the tunnel entrances. For safety reasons each of the two entrances has railings which are modeled as TunnelInstallation. Due to the high geometrical accuracy and the semantic richness, the model is classified as LOD3.

10.5.  Bridge model

The bridge model allows for the representation of the thematic, spatial and visual aspects of bridges and bridge parts in four levels of detail, LOD 1 — 4. The bridge model of CityGML is defined by the thematic extension module Bridge (cf. Clause 7). Figure 50 illustrates examples of bridge models in all LODs.

Figure 50 — Examples for bridge models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left) and LOD4 (lower right) (source: Google 3D warehouse)

The bridge model was developed in analogy to the building model (cf. Clause 10.3) with regard to structure and attributes. The UML diagram of the bridge model is depicted in Figure 51, and the XML schema definition is presented in Annex A.3.

Figure 51 — UML diagram of the bridge model, part one.

A (movable or unmovable) bridge is represented by an object of the class Bridge. This class inherits its attributes and relations from the abstract base class _AbstractBridge. The spatial properties are defined by a solid for each of the four LODs (relations lod1Solid to lod4Solid). In analogy to the building model, the semantical as well as the geometrical richness increases from LOD1 (blocks model) to LOD3 (architectural model). Simple examples of bridges in each of those LODs are depicted in Figure 52. Interior structures like rooms are dedicated to LOD4. To cover the case of bridge models where the topology does not satisfy the properties of a solid (essentially water tightness), a multi surface representation is allowed (lod1MultiSurface to lod4MultiSurface). The line where the bridge touches the terrain surface is represented by a terrain intersection curve, which is provided for each LOD (relations lod1TerrainIntersection to lod4TerrainIntersection). In addition to the solid representation of a bridge, linear characteristics like ropes or antennas can be specified geometrically by the lod1MultiCurve to lod4MultiCurve relations. If those characteristics shall be represented semantically, the features BridgeInstallation or BridgeConstructionElement can be used (see Clause 10.5.2). All relations to semantic objects and geometric properties are listed in Table (??).

Figure 52 — Bridge model in LOD1 — LOD4. (source: Karlsruhe Institute of Technology (KIT))

The semantic attributes of an _AbstractBridge are class, function, usage and is_movable. The attribute class is used to classify bridges, e.g. to distinguish different construction types (cf. Figure 54). The attribute function allows representing the utilization of the bridge independently of the construction.Possiblevalues may be railway bridge, roadway bridge, pedestrian bridge, aqueduct, etc. The option to denote a usage which is divergent to one of the primary functions of the bridge (function) is given by the attribute usage. The type of these attributes is gml:CodeType, the values of which can be defined in code lists. The name of the bridge can be represented by the gml:name attribute, which is inherited from the base class gml: _GML via the classes gml: _Feature, _CityObject, and _Site. Each Bridge or BridgePart feature may be assigned zero or more addresses using the address property. The corresponding AddressPropertyType is defined within the CityGML core module (cf. Clause 10.1.4).

Table — Semantic themes of the class _AbstractBridge.

The boolean attribute is_movable is defined to specify whether a bridge is movable or not. The modeling of the geometric aspects of the movement is delayed to later versions of this standard. Some types of movable bridges are depicted in Figure 53.

Figure 53 — Examples for movable bridges (source: ISO 6707).

Figure 54 — Examples for different types of bridges.

XML namespace

The XML namespace of the CityGML Bridge module is identified by the Uniform Resource Identifier (URI) http://www.opengis.net/citygml/bridge/2.0. Within the XML Schema definition of the Bridge module, this URI is also used to identify the default namespace.

<xs:complexType name=”BridgeType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBridgeType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfBridge” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Bridge” type=”BridgeType” substitutionGroup=”_AbstractBridge”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBridge” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”BridgeType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBridgeType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfBridge” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”Bridge” type=”BridgeType” substitutionGroup=”_AbstractBridge”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBridge” type=”xs:anyType” abstract=”true”/>

<xs:complexType name=”AbstractBridgeType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractSiteType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”yearOfConstruction” type=”xs:gYear” minOccurs=”0”/>
				<xs:element name=”yearOfDemolition” type=”xs:gYear” minOccurs=”0”/>
				<xs:element name=”isMovable” type=”xs:boolean” default=”false” minOccurs=”0”/>
				<xs:element name=”lod1Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod1MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod1TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod2Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod2MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod2TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”outerBridgeConstruction” type=”BridgeConstructionElementPropertyType” minOccurs=”0”
										maxOccurs=”unbounded”/>
				<xs:element name=”outerBridgeInstallation” type=”BridgeInstallationPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”interiorBridgeInstallation” type=”IntBridgeInstallationPropertyType” minOccurs=”0”
										maxOccurs=”unbounded”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod3Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4Solid” type=”gml:SolidPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiCurve” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”interiorBridgeRoom” type=”InteriorBridgeRoomPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”consistsOfBridgePart” type=”BridgePartPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”address” type=”core:AddressPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfAbstractBridge” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”_AbstractBridge” type=”AbstractBridgeType” abstract=”true” substitutionGroup=”core:_Site”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfAbstractBridge” type=”xs:anyType” abstract=”true”/>

10.5.2.  Bridge construction elements and bridge installations

<xs:complexType name=”BridgeConstructionElementType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod1Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod2Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod3Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod1TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod2TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4TerrainIntersection” type=”gml:MultiCurvePropertyType” minOccurs=”0”/>
				<xs:element name=”lod1ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod2ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod3ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfBridgeConstructionElement” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”BridgeConstructionElement” type=”BridgeConstructionElementType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBridgeConstructionElement” type=”xs:anyType”/>

BridgeConstructionElementType, BridgeConstructionElement

<xs:complexType name=”BridgeInstallationType”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”class” type=”gml:CodeType” minOccurs=”0”/>
				<xs:element name=”function” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”usage” type=”gml:CodeType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element name=”lod2Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod3Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4Geometry” type=”gml:GeometryPropertyType” minOccurs=”0”/>
				<xs:element name=”lod2ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod3ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”lod4ImplicitRepresentation” type=”core:ImplicitRepresentationPropertyType” minOccurs=”0”/>
				<xs:element name=”boundedBy” type=”BoundarySurfacePropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfBridgeInstallation” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”BridgeInstallation” type=”BridgeInstallationType” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfBridgeInstallation” type=”xs:anyType” abstract=”true”/>

BridgeInstallationType, BridgeInstallation

Bridge elements which do not have the size, significance or meaning of a BridgePart can be modelled either as BridgeConstructionElement or as BridgeInstallation. Elements which are essential from a structural point of view are modelled as BridgeConstructionElement, for example structural elements like pylons, anchorages etc. (cf. Figure 55). A general classification as well as the intended and actual function of the construction element are represented by the attributes class, function, and usage. The geometry of a BridgeConstructionElement, which may be present in LOD1 to LOD4, is gml:_Geometry. Alternatively, the geometry may be given as ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype bridge construction element is stored only once in a local coordinate system and referenced by other bridge construction element features (cf. Clause 8.2). The visible surfaces of a bridge construction element can be semantically classified using the concept of boundary surfaces (cf. Clause 10.5.3).

Whereas a BridgeConstructionElement has structural relevance, a BridgeInstallation represents an element of the bridge which can be eliminated without collapsing of the bridge (e.g. stairway, antenna, railing). BridgeInstallations occur in LOD 2 to 4 only and are geometrically representated as gml:_Geometry. Again, the concept of ImplicitGeometry can be applied to BridgeInstallations alternatively, and their visible surfaces can be semantically classified using the concept of boundary surfaces (cf. Clause 10.5.3). The class BridgeInstallation contains the semantic attributes class, function and usage. The attribute class gives a classification of installations of a bridge. With the attributes function and usage, nominal and real functions of the bridge installation can be described. The type of all attributes is gml:CodeType and their values can be defined in code lists.

Figure 55 — BridgeConstructionElements of a suspension bridge.

10.5.3.  Boundary surfaces

<xs:complexType name=”AbstractBoundarySurfaceType” abstract=”true”>
	<xs:complexContent>
		<xs:extension base=”core:AbstractCityObjectType”>
			<xs:sequence>
				<xs:element name=”lod2MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod3MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”lod4MultiSurface” type=”gml:MultiSurfacePropertyType” minOccurs=”0”/>
				<xs:element name=”opening” type=”OpeningPropertyType” minOccurs=”0” maxOccurs=”unbounded”/>
				<xs:element ref=”_GenericApplicationPropertyOfBoundarySurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”_BoundarySurface” type=”AbstractBoundarySurfaceType” abstract=”true” substitutionGroup=”core:_CityObject”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfBoundarySurface” type=”xs:anyType” abstract=”true”/>

AbstractBoundarySurfaceType, _BoundarySurface

The thematic boundary surfaces of a bridge are defined in analogy to the building module. _BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a bridge as well as the visible surfaces of rooms, bridge construction elements and both outer and interior bridge installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry.

In LOD3 and LOD4, a _BoundarySurface may contain _Openings (cf. Clause 10.5.4) like doors and windows. If the geometric location of _Openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these _Openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door, a Window, or a ClosureSurface, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an Opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the Opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface.

Figure 56 depicts a bridge with RoofSurfaces, WallSurfaces, OuterFloorSurfaces and OuterCeilingSurfaces. Besides Bridges and BridgeParts, BridgeConstructionElements, BridgeInstallations as well as IntBridgeInstallations can be related to _BoundarySurface. _BoundarySurfaces occur in LOD2 to LOD4. In LOD3 and LOD4, such a surface may contain _Openings (see Clause 10.3.4) like doors and windows.

Figure 56 — Different BoundarySurfaces of a bridge.

<xs:complexType name=”GroundSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfGroundSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”GroundSurface” type=”GroundSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfGroundSurface” type=”xs:anyType” abstract=”true”/>

GroundSurfaceType, GroundSurface

The ground plate of a bridge or bridge part is modelled by the class GroundSurface. The polygon defining the ground plate is congruent with the bridge’s footprint. However, the surface normal of the ground plate is pointing downwards.

<xs:complexType name=”OuterCeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterCeilingSurface” type=”OuterCeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterCeilingSurface” type=”xs:anyType” abstract=”true”/>

OuterCeilingSurfaceType, OuterCeilingSurface

A mostly horizontal surface belonging to the outer bridge shell and having the orientation pointing downwards can be modeled as an OuterCeilingSurface.

<xs:complexType name=”WallSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfWallSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”WallSurface” type=”WallSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfWallSurface” type=”xs:anyType” abstract=”true”/>

WallSurfaceType, WallSurface

All parts of the bridge facade belonging to the outer bridge shell can be modelled by the class WallSurface.

<xs:complexType name=”OuterFloorSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfOuterFloorSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”OuterFloorSurface” type=”OuterFloorSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfOuterFloorSurface” type=”xs:anyType” abstract=”true”/>

OuterFloorSurfaceType, OuterFloorSurface

A mostly horizontal surface belonging to the outer bridge shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface.

<xs:complexType name=”RoofSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfRoofSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================== —>
<xs:element name=”RoofSurface” type=”RoofSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================== —>
<xs:element name=”_GenericApplicationPropertyOfRoofSurface” type=”xs:anyType” abstract=”true”/>

RoofSurfaceType, RoofSurface

The major roof parts of a bridge or bridge part are expressed by the class RoofSurface.

<xs:complexType name=”ClosureSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfClosureSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”ClosureSurface” type=”ClosureSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfClosureSurface” type=”xs:anyType” abstract=”true”/>

ClosureSurfaceType, ClosureSurface

An opening in a bridge not filled by a door or window can be sealed by a virtual surface called ClosureSurface (cf. Clause 6.4). Hence, bridge with open sides can be virtually closed in order to be able to compute their volume. ClosureSurfaces are also used in the interior bridge model. If two rooms with a different are directly connected without a separating door, a ClosureSurface should be used to separate or connect the volumes of both rooms.

<xs:complexType name=”ClosureSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfClosureSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”ClosureSurface” type=”ClosureSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfClosureSurface” type=”xs:anyType” abstract=”true”/>

FloorSurfaceType, FloorSurface

The class FloorSurface must only be used in the LOD4 interior bridge model for modelling the floor of a bridge room.

<xs:complexType name=”InteriorWallSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfInteriorWallSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”InteriorWallSurface” type=”InteriorWallSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfInteriorWallSurface” type=”xs:anyType” abstract=”true”/>

InteriorWallSurfaceType, InteriorWallSurface

The class InteriorWallSurface must only be used in the LOD4 interior bridge model for modelling the visible surfaces of the bridge room walls.

<xs:complexType name=”CeilingSurfaceType”>
	<xs:complexContent>
		<xs:extension base=”AbstractBoundarySurfaceType”>
			<xs:sequence>
				<xs:element ref=”_GenericApplicationPropertyOfCeilingSurface” minOccurs=”0” maxOccurs=”unbounded”/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!— ========================================================================================= —>
<xs:element name=”CeilingSurface” type=”CeilingSurfaceType” substitutionGroup=”_BoundarySurface”/>
<!— ========================================================================================= —>
<xs:element name=”_GenericApplicationPropertyOfCeilingSurface” type=”xs:anyType” abstract=”true”/>

CeilingSurfaceType, CeilingSurface

The class CeilingSurface must only be used in the LOD4 interior bridge model for modelling the ceiling of a bridge room.